BoxLite Flaw Allows Sandbox Escape, Host File Modification

A critical vulnerability has been discovered in BoxLite, a service for running untrusted code in lightweight sandboxes. The flaw, tracked as CVE-2026-46695, permits code executing inside a sandbox to bypass filesystem permissions. An attacker can modify host files that were mounted as read-only, creating a path for a full sandbox escape and host system compromise [1]. The vulnerability is especially dangerous in AI agent deployments, where sandboxing is a primary defense against malicious code generated by language models.

The Attack Chain: From Read-Only to Root

The exploit begins from a position of control inside a BoxLite container. This is the intended operating model for the tool, which is designed to run untrusted code provided by a user or an automated process.

The attack targets a core security feature: mounting a host directory into the container as a read-only volume. While the initial mount prevents direct writes, the container's configuration grants it excessive privileges.

An attacker can use the standard `mount` command with the `-o remount,rw` flag to change the read-only volume to read-write. This command succeeds because BoxLite, by default, granted the container the powerful `CAP_SYS_ADMIN` capability, which permits such administrative operations [2].

Once remounted, the sandboxed code has full write access to the host directory. This allows an attacker to modify application code, inject malicious dependencies into a shared virtual environment, or alter configuration files to achieve code execution on the host.

A Broken Promise in the API

The vulnerability stems from a discrepancy between the BoxLite API's documented behavior and its implementation. Developers using the `VolumeSpec` API are presented with a `read_only` boolean flag, creating a clear expectation of enforcement.

Code analysis reveals this `read_only` flag is never passed to the underlying `libkrun` hypervisor library. The hypervisor itself is unaware of any read-only restriction and exposes the shared filesystem to the guest VM with full read-write permissions at the device level.

Instead of hypervisor-level enforcement, BoxLite delegated the responsibility to an agent running inside the guest. This agent was instructed to apply a read-only flag during the initial mount. This approach is fundamentally insecure, as it relies on the untrusted environment to enforce its own security policy.

The failure was compounded by granting all 41 Linux capabilities to the container. This "maximum compatibility" setting provided the `CAP_SYS_ADMIN` privilege needed to undo the guest-side protection, rendering the read-only flag ineffective [1].

The Impact on Agentic Systems

This vulnerability poses a severe threat to systems deploying autonomous AI agents. These systems rely heavily on sandboxing technologies like BoxLite to contain the actions of code generated by large language models.

An attacker could use prompt injection to trick an agent into generating and executing exploit code. Alternatively, a malicious or compromised AI model could be used to directly attack the host infrastructure. The vulnerability breaks the essential trust boundary between the agent's workspace and the host machine.

The impact extends to supply chain risks. Many agentic workflows mount host directories containing source code, credentials, or Python virtual environments. By modifying these shared resources, an attacker can achieve persistence and compromise other applications or workflows on the same host.

Remediation: A Defense-in-Depth Fix

The BoxLite team has released version 0.9.0 to address this critical vulnerability. The fix was committed in pull request #454 and provides a multi-layered defense against this and similar attack vectors [3].

The primary fix moves enforcement to the correct trust boundary. The `read_only` flag is now passed to the hypervisor using an updated `libkrun` library, making the filesystem share read-only at the virtual device level. This prevents a guest from overriding the setting.

As a second layer of defense, BoxLite now follows the principle of least privilege. Instead of granting all capabilities, containers are now restricted to a default set of 14, which explicitly excludes `CAP_SYS_ADMIN`. This change alone would have prevented the remount attack.

A third fix tightens network isolation when networking is disabled. The update reinforces the sandbox boundary, demonstrating a comprehensive security overhaul. Upgrading is mandatory, as no workaround exists for vulnerable versions [4].