Inspektor Gadget Security Audit

TL;DR

In early 2026, Shielder was hired by OSTIF to perform a security audit of Inspektor Gadget, an eBPF-based framework that provides powerful and flexible observability tools for Kubernetes and Linux hosts.

Today, we are publishing the full report in our dedicated repository.

Context

Inspektor Gadget is both a framework and a toolkit to enhance observability on a Linux machine/Kubernetes node, using the eBPF technology. Inspektor Gadget manages the packaging, deployment and execution of “gadgets”, which are essentially eBPF programs encapsulated in OCI images. Gadgets export events that are caught by the tool and that can be filtered, sorted, exported or enriched.

See it in action:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

$ kubectl gadget run trace_open:latest --podname mypod
K8S.NODE           K8S.NAMESPACE K8S.PODNAME   K8S.CONTAINE… COMM        PID     TID      FD FNAME                    MODE    ERROR
minikube-docker    default       mypod         mypod         true     511559  511559       0 /etc/ld.so.cache         ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/g… ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/g… ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/t… ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/t… ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/t… ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/t… ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/x… ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/x… ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/x… ------… ENOEN
minikube-docker    default       mypod         mypod         true     511559  511559       0 /lib/x86_64-linux-gnu/l… ------… ENOEN
...
minikube-docker    default       mypod         mypod         whoami   511560  511560       0 /lib/x86_64/libm.so.6    ------… ENOEN
minikube-docker    default       mypod         mypod         whoami   511560  511560       3 /lib/libm.so.6           ------…
minikube-docker    default       mypod         mypod         whoami   511560  511560       3 /lib/libresolv.so.2      ------…
minikube-docker    default       mypod         mypod         whoami   511560  511560       3 /lib/libc.so.6           ------…
minikube-docker    default       mypod         mypod         whoami   511560  511560       3 /etc/passwd              ------…
^C

Before starting the audit, we sit with the maintainers for a collaborative threat modeling session. With open source projects, we have found this to be crucial: just looking at the code often does not yield the most interesting information, that is, how end-users install, configure and use the project.

As a result, two main points emerged:

1. In order to load eBPF code in the kernel, Inspektor Gadget needs a privileged account/role in the system (typically root, or at the very least, the all-powerful CAP_SYS_ADMIN capability). This makes it a clear target for privilege escalation scenarios, both on standalone Linux hosts and Kubernetes clusters.
2. Inspektor Gadget provides ready-to-use gadgets (such as the trace_open used in the example above). One of the main reasons operators might want observability in their cluster is to build security monitoring; but if the tracing can be bypassed, attackers could execute operations on the host without generating events/alerts.

With these attack scenarios in mind, we have performed the audit by combining manual and AI-assisted analysis, dynamic testing, and usage of SAST tooling such as semgrep and gosec.

Findings

While auditing, we have discovered three vulnerabilities (two with Medium severity, one with Low) that we reported through the project Github Security portal:

Command Injection in ig build

Inspektor Gadget provides the tooling to build, push and pull custom gadgets (https://inspektor-gadget.io/docs/latest/gadget-devel/). The building flow uses Makefile variable interpolation, which is prone to command injections, if an attacker controls some of the variables that are used to build new gadgets. This could be leveraged by attackers, for instance, to gain code execution in CI/CD runners. The severity was set to Medium/Moderate, given the added complexity of controlling the build variables.

The maintainers fixed this in version v0.51.1 by refactoring the building process to use Golang machinery rather than Makefiles.

Denial of Service via Event Flooding

Inspektor Gadget captures all the events coming from deployed gadgets in a single kernel ring-buffer, with a size that is hard-coded to 256KB. When the gadgets push more events than what the user-space collector can handle, this buffer can be filled completely, leading to new events being dropped. Inspektor Gadget silently ignored those dropped packets, which would allow an attacker to first produce many harmless events to flood the buffer, and then perform malicious operations that would not be caught by any gadget. The severity was set to Medium/Moderate, as this only affects the integrity of the observation pipeline.

The maintainers fixed this by implementing a map of dropped packets to detect when events are being lost, so that users can build alerts on top of this limitation.

Unsanitized ANSI Escape Sequences in Columns Output Mode

When displaying gadget events through a terminal using the default output formatter, there was no sanitization of control characters of ANSI escape sequences. Therefore, an attacker in a container could craft malicious events (for instance, by opening/creating files with controlled names) to inject these in the terminal. The impact depends on what terminal is used - at the very least, it could be used to inject new logs or delete existing ones. The severity was set to Low, as this already required a compromised pod in the cluster, and the exploitability highly varies on the terminal used.

The maintainers fixed this by sanitizing the text before sending it to the terminal.

Hardenings

During the audit, we gathered some recommendations for the project to improve its security posture:

• Enforce TLS on TCP Listeners: when starting an ig daemon, TLS must be enabled with a flag, and the default is an insecure channel. We recommended switching to a default secure policy.
• Supply Chain Hash Pinning: some dependencies in CI/CD actions are not pinned by hash, which might be leveraged by attackers to compromise the supply chain and push malicious code (and gadgets) to the project. We recommended adding a specific hash/commit to every dependency, and avoid pulling from latest.
• Kubernetes Namespace Blocklist: on Kubernetes, gadgets can be used to inspect containers running in every namespace. This would include sensitive namespaces such as kube-system, where tracing sensitive actions might be leveraged to compromise the cluster. We recommended adding a customizable block-list of namespaces.
• Prevent Clients from Enabling Host Tracing: on Linux standalone hosts, clients connecting via gadgetctl can enable full-host tracing, which captures events in the host rather than in the running containers, which could be exploited to leak sensitive data from the host, such as passwords or other secrets. We initially reported this as a vulnerability, but the maintainers stated that this fits the threat model of the project, as gadgetctl operators are considered trusted parties. Nevertheless, we included this finding in the report to inform end-users of this attack scenario.
• Automate Third Party Vulnerability Scanning: we recommended integrating, in the CI/CD pipeline of the project, a dependency scanner such as the Google osv-scanner to detect known vulnerabilities in direct or indirect dependencies. By running this tool against the project, we have found that some of the tools in the project are pinned to Golang versions that are known to be vulnerable.
• The Dangerous GET nodes/proxy Permission: The RBAC role assigned to the Pod where Inspektor Gadget is deployed, on Kubernetes, owns the infamously notorious GET on nodes/proxy permission. This could be leveraged by a compromised DaemonSet to gain code execution on other nodes in the cluster. The permission was needed in the initial phase of node discovery. We collaborated with the maintainers to design a new bootstrap mechanism that does not need this permission.

Gadget Bypasses

As mentioned in the Context section, as part of the audit, we have also audited the official gadgets distributed with the project, with the goal of finding bypasses that could sneak past the tracing:

• trace_open bypass via openat2: an attacker might open files without an event being generated by using the sys_enter_openat2 syscall, introduced in Linux 5.6.
• trace_mount bypass via fs*: an attacker might operate on mounts without an event being generated by using the fsopen/fsconfig/fsmount/move_mount API introduced in Linux 5.2.
• tcpdump bypass via jumbo frames: an attacker might create data in packets that are not captured by the tcpdump gadget by creating frames with a bigger size than 1500 bytes (also known as jumbo frames).
• trace_sni bypass via IPv6: an attacker might negotiate TLS connections without the SNI being traced by using IPv6 rather than IPv4.
• uprobe-based gadgets bypass via static linking: some gadgets, such as trace_malloc, implement tracing by “hooking” dynamically linked libraries such as libc.so. An attacker might completely bypass these gadgets by either statically linking the libraries, or directly invoking the syscalls underneath.
• evasion via io_uring: multiple gadgets implement tracing by hooking syscalls’ entry/exit tracepoints. However, an attacker might abuse the io_uring API to invoke syscalls in a way that would evade the tracing (this would only work in containers running with seccomp unconfined, though).

Some of these bypasses can be fixed by hardening the gadgets, but for other intrinsic bypasses, such as those that instrument dynamic libraries, we have recommended adding specific documentation on the limitations, so that end-users know where the tracing could fall short.

Conclusions

Inspektor Gadget leverages eBPF to provide a simple yet flexible tracing layer to Linux and Kubernetes, in a polished way that is trivial for users to configure and deploy.

When running on Kubernetes, the gadgets can piggyback on the existing authentication and authorization layer, providing a “safe by default” solution that is harder to abuse and compromise. On the other hand, for the Linux standalone deployment via ig daemon, it is recommended to harden the configuration manually, by enforcing TLS on the listener, and treating every gadgetctl operator as a trusted privileged user.

In production environments, when using Inspektor Gadget as a security monitoring solution, it is the usual cat and mouse game: provided enough freedom on a compromised container, it is quite possible for attackers to devise mechanisms to evade the tracing offered by the tool. However, even though bypass is feasible, the framework can and should still be used as another layer in a well hardened defense-in-depth strategy.

Notably, we have found the core maintainers of Inspektor Gadget - namely Francis Laniel and Mauricio Vasquez - to be very collaborative and, honestly, unusually fast at triaging and fixing the issues which we have reported. Also, they have been happy and available to discuss together future improvements to the security posture of the project.

It was a pleasure for our team to work with them, with OSTIF, and with the CNCF.

Pitch 🗣

Did you know OSTIF helps sensitive open-source projects in securing funds to perform security audits? They will also help you in scoping the assessment, finding a trusted partner to perform the analysis, and ensuring full transparency along the way.

P.S. if you need help in threat modeling and auditing your projects –> get in touch with us!