Inspektor Gadget — the open source toolkit built on eBPF for observing Kubernetes clusters and inspecting Linux hosts — has successfully completed its first independent security audit. The Open Source Technology Improvement Fund (OSTIF) coordinated the effort, with funding from the CNCF and the actual assessment performed by Shielder. All findings, along with the corresponding fixes and hardening suggestions, have been made publicly available, and patches exist for every reported vulnerability.
This article explains what Inspektor Gadget is, how the audit was structured, what the researchers discovered, and what the outcomes mean for teams using it in production environments.
What is Inspektor Gadget?
Inspektor Gadget is a framework and toolkit that leverages eBPF to gather and analyze data across Kubernetes clusters and Linux hosts. It handles the packaging, deployment, and execution of “gadgets” — eBPF programs distributed as OCI images. OCI (Open Container Initiative) is a Linux Foundation initiative that establishes open industry standards for container image formats and runtimes, ensuring images can be shared and executed across any compatible tool or registry.
For teams operating Kubernetes in production that need deep insight into cluster activity, Inspektor Gadget delivers that visibility without the typical compromises. There’s no need to rebuild container images with additional instrumentation, inject sidecars into every pod, attach debuggers or strace to live processes, restart workloads to enable or disable tracing, or deploy custom kernel modules to nodes. Instead, eBPF programs are loaded into the kernel at runtime to safely monitor syscalls, network traffic, and file access. Applications continue running without modification while operators obtain the information they require.
Why conduct a security audit?
Any utility that operates with elevated privileges on shared infrastructure must earn user trust. Inspektor Gadget requires root-level access on nodes to function, so an independent evaluation of its security posture is a logical step as the project matures and its user base expands.
OSTIF is a nonprofit organization focused on strengthening the security of open source software. Over the last decade, OSTIF has overseen security assessments that have revealed more than 800 vulnerabilities across 120 open source projects.
How the audit was structured
OSTIF contracted Shielder to carry out the evaluation. Two researchers conducted the audit in early 2026 using a methodology that included:
- Collaborative threat modeling sessions with the Inspektor Gadget maintainers
- Hands-on manual source code review
- Dynamic testing within dedicated lab environments
- Static analysis with tools including Semgrep and GoSec
- AI-assisted code review to broaden coverage
The researchers set up three test environments mirroring real-world Inspektor Gadget deployments: a local Linux host setup, a remote daemon configuration, and a Kubernetes deployment running on minikube.
What the audit uncovered
The audit revealed three vulnerabilities. None were classified as Critical or High severity.
Two Medium severity issues
- Command injection in ig image build (CVE-2026-24905). The image build workflow relied on Makefiles that incorporated user-supplied input without adequate escaping, opening a command injection pathway. This is particularly relevant for CI/CD pipelines that build untrusted gadgets. Resolved in release v0.48.1.
- Denial of service through event flooding. A malicious container could overwhelm the eBPF ring buffer (set at a fixed 256 KB), causing the system to silently discard events originating from other containers. For teams relying on Inspektor Gadget within a security monitoring pipeline, an attacker could exploit this to conceal malicious activity by flooding the system with noise. Resolved in release v0.50.1.
One Low severity issue
- Unsanitized ANSI escape sequences in columns output mode (CVE-2026-25996). When displaying events in the terminal, Inspektor Gadget failed to strip ANSI escape sequences, enabling a compromised container to inject terminal escape codes into an operator’s terminal output. Resolved in release v0.49.1.
Hardening recommendations
In addition to the specific vulnerabilities, Shielder provided six hardening recommendations. These are not active exploits — they represent opportunities for the project to shrink its attack surface over time:
- Enforce TLS by default on TCP listeners. Currently, when the daemon launches a TCP listener without TLS, it logs a warning and proceeds with plaintext communication. The recommendation is to require an explicit opt-out flag instead.
- Pin and verify external dependencies in CI/CD. Several build dependencies were fetched without hash or signature verification. The project has already implemented fixes or has pull requests in progress for most of these.
- Introduce a Kubernetes namespace blocklist to prevent accidental tracing on sensitive namespaces such as kube-system.
- Restrict remote clients from activating host-level tracing through the daemon, or clearly document the associated risk.
- Automate third-party vulnerability scanning for project dependencies.
- Reduce RBAC permissions on the DaemonSet pod — specifically the nodes/proxy GET permission, which could be exploited for privilege escalation if the service account token is compromised.
The maintainers are addressing these recommendations methodically. Some have already been merged; others, particularly the RBAC refactor and namespace blocklist, will require additional time.
Gadget bypass testing
One of the most technically compelling aspects of the audit was the gadget bypass testing. The researchers investigated whether a compromised container could carry out operations that a gadget is designed to trace without generating any events. They identified six bypass scenarios, ranging from leveraging newer Linux syscalls that certain gadgets don’t intercept (such as openat2 instead of openat) to evasion techniques involving io_uring and statically linked libraries.
These findings reflect the ongoing cat-and-mouse dynamic inherent in kernel-level tracing. Linux continues to evolve, with new syscalls and subsystems emerging regularly, and eBPF-based tracing tools must continuously adapt. The Inspektor Gadget maintainers have already closed several of the identified gaps and are documenting the inherent limitations of the approach so that operators have a clear understanding of what eBPF tracing can and cannot guarantee.
What this means for users
The key takeaway for organizations running Inspektor Gadget is to upgrade to v0.50.1 or later, which contains fixes for all three reported vulnerabilities. Shielder’s own assessment, drawn from the final report, states that “the overall security posture of Inspektor Gadget is adequately mature from both a secure coding and design point of view.”
For the broader cloud native community, this audit serves as a model for how the ecosystem should function. A project reaches a stage of adoption where an independent security review becomes essential, OSTIF coordinates a qualified engagement, researchers conduct their work transparently, maintainers implement the fixes, and the complete report is published so that users can make well-informed decisions.
