# Sandbox Escape - Permissive Syscall Abuse in Agent Code Execution (FastGPT Sandbox)

- **Severity:** High
- **Signature ID:** `7b3c9d24-5f81-4a6e-9d0b-2c14e8f37a56`

## Summary

An attacker who can run code inside a FastGPT sandbox (versions before 4.9.11) can use that access to break out of the container and touch the underlying host. The sandbox lets scripts call dangerous low-level system functions it should have blocked.

## How the attack works

The attacker first gets arbitrary code executed inside the sandbox, typically through an AI agent that runs user-supplied Python, Node, or shell one-liners. That inline code then calls libc directly (via ctypes or similar) to invoke syscalls like ptrace, mount, unshare, setns, init_module, process_vm_writev, or open_by_handle_at, or it invokes a breakout binary such as nsenter directly. These calls let the code cross container namespace boundaries into the host, and separately, reflection tricks like __subclasses__ or __builtins__ can bypass any interpreter-level import restrictions meant to stop this. Once across the boundary, the attacker can read and write arbitrary files on the host system.

## Why it matters

A successful escape gives the attacker access to the host machine running the AI agent's sandbox, not just the isolated execution environment, which can lead to full host compromise, data theft, or tampering with other workloads on the same system.

## What you can do

- Upgrade fastgpt-sandbox to 4.9.11 or later, where the syscall set is restricted.
- Apply a tighter seccomp/AppArmor profile or Kubernetes securityContext to the sandbox container that blocks ptrace, mount, unshare, setns, init_module, process_vm_writev, and open_by_handle_at.
- Review logs for process command lines that combine inline code execution (python -c, node -e, interpreter heredocs) with these syscalls or breakout binaries like nsenter.
- Restrict what code an AI agent can pass into the sandbox, and avoid granting the sandbox container elevated Linux capabilities such as CAP_SYS_ADMIN.

## Known benign look-alikes

- Security or platform engineers authoring/linting seccomp, AppArmor or Kubernetes securityContext policy that enumerates syscall and capability names such as SYS_ptrace or CAP_SYS_ADMIN - suppressed by filter_policy_authoring.
- Code-review or triage agents grepping a repository for sandbox-escape indicators (__subclasses__, ctypes.CDLL, nsenter) - suppressed by filter_search_tooling.
- Documentation, advisory or PoC writing about this exact FastGPT sandbox issue - suppressed by filter_security_docs.
- Rootless-container and CI tooling that legitimately runs `unshare --user --map-root-user` or `mount -t proc` during image or namespace setup; not suppressed, because the same command line is the escape itself. Expect these on build/CI hosts and tune per fleet.
- Legitimate low-level platform probing via ctypes (for example calling libc.prctl to set a thread name). The libc selection is restricted to escape-relevant symbols, but a developer tool that calls libc.prctl inline will still match.
- Test suites for a sandbox implementation that intentionally exercise interpreter introspection or namespace syscalls from an inline `python -c` harness.

## References

- https://github.com/labring/FastGPT/releases
- https://owasp.org/Top10/A04_2021-Insecure_Design/
- https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/
- https://attack.mitre.org/techniques/T1611/
- https://attack.mitre.org/techniques/T1068/

---
Source: https://www.netzilo.com/threats/fastgpt-sandbox-escape-syscalls