Linux can recognize a non-native executable and hand it to an interpreter through binfmt_misc. The mechanism is useful for emulation, language runtimes, and cross-platform build systems. It also creates an execution path that may be invisible in a normal review of file permissions.
The kernel documentation describes registration through /proc/sys/fs/binfmt_misc/register. A registration string identifies a binary type by magic bytes or filename extension and names an interpreter. Once registered, executing a matching file can invoke that interpreter instead of returning an ordinary format error. The interpreter path and mount namespace therefore belong to the security boundary.
The namespace changes the evidence
binfmt_misc is mounted as a filesystem. A container, service manager, or test runner may have its own view of that mount and its own registrations. A host-level registration is not necessarily visible inside a container, and a registration made inside an unprivileged namespace is not automatically harmless. The kernel documentation discusses pre-opened interpreter handling and namespace limits because interpreters can be pinned across execution.
The security question is not only whether a user can create a file. It is whether a matching file will invoke a trusted interpreter with a controlled argument vector, environment, and credentials. An interpreter that runs with more privilege than the caller can turn a dropped file into privilege escalation. A registration that points to a mutable path can change behavior after review. A broad magic pattern can capture files that were never intended to be executable.
Review the registrations, then test them
List the mount state, every registration entry, the interpreter path, the flags, and the owning namespace. Compare those entries with the build, emulation, and packaging systems that are supposed to use them. Remove stale entries and prefer immutable paths for interpreters. Restrict the ability to write to the registration interface and to replace the interpreter binary.
Test from the same user, mount namespace, and container image used in production. Create a benign file that matches a registration and confirm which process executes. Then test a file that should not match and verify that it fails without invoking an interpreter. Check whether the application records the interpreter path or only the original filename.
Container images should be rebuilt when registrations or interpreter paths change. Restoring an old image can reintroduce a registration that the host has removed. Node inventories should distinguish the host registration from the container runtime's view.
binfmt_misc is not malicious by design. It is a kernel extension point that deserves the same ownership, change control, and negative testing as a setuid binary or a privileged service unit.