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**.

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:

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:

`root, or at the very least, the all-powerful` `CAP_SYS_ADMINcapability). This makes it a clear target for privilege escalation scenarios, both on standalone Linux hosts and Kubernetes clusters.` `trace_openused 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`.

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:

`ig daemon, TLS must be enabled with a flag, and the default is an insecure channel. We recommended switching to a default secure policy.` `latest.` `kube-system, where tracing sensitive actions might be leveraged to compromise the cluster. We recommended adding a customizable block-list of namespaces.` `gadgetctlcan 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` `gadgetctloperators are considered trusted parties. Nevertheless, we included this finding in the report to inform end-users of this attack scenario.`

**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:

`openat2` `sys_enter_openat2syscall, introduced in Linux 5.6.` `fs*` `fsopen/fsconfig/fsmount/move_mountAPI introduced in Linux 5.2.` `tcpdumpgadget by creating frames with a bigger size than 1500 bytes (also known as jumbo frames).` `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.` `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.

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.

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!

Date

30 April 2026

Author

Security Researcher and Penetration Tester at Shielder. Human, Chaotic Good. Disciple of Bushido & Disney.

Previous post