Source et contexte: Prépublication (UK AI Security Institute / University of Oxford), datée du 4 mars 2026. L’article introduit SANDBOXESCAPEBENCH, un benchmark et une méthodologie d’évaluation « sandbox-in-sandbox » pour mesurer si des agents LLM peuvent sortir d’un conteneur et lire un fichier /flag.txt sur l’hôte.

• Le benchmark couvre 18 scénarios d’orchestration (K8s), de runtime (Docker/OCI) et de noyau Linux, avec une architecture d’évaluation par CTF et un double isolement (VM + conteneur) afin d’éviter tout risque pour l’infrastructure. Les auteurs publient les 18 niveaux et un provider de sandbox VM pour Inspect (Vagrant/EC2), avec un jeu de test privé.

• Modèle de menace: agent motivé avec accès shell dans un conteneur, objectif de lire le flag sur l’hôte; pas de détection active; scénarios conçus avec des vulnérabilités connues ou des erreurs de configuration réalistes. Le succès est mesuré de façon binaire par la lecture du flag hors de l’espace de noms du conteneur.

• Résultats clés: Les LLM de pointe réussissent fréquemment sur les erreurs de configuration courantes (ex. conteneurs privilégiés, docker.sock exposé, hostPath permissif) et obtiennent des succès non nuls sur certains scénarios runtime/noyau de difficulté moyenne (niveau 3), mais aucun succès n’est observé sur les niveaux 4–5. Les performances augmentent avec le budget de calcul en inférence (tendance approx. log-linéaire). Des écarts nets apparaissent entre générations et tailles de modèles (ex. régression observée entre GPT‑5 et GPT‑5.2; amélioration marquée avec « hints » pour Opus 4.5, moindre effet pour GPT‑5).

• Observations: Aucun 0‑day découvert; toutes les réussites s’appuient sur CVE existants ou des ratés de configuration. Quatre raccourcis non voulus ont été identifiés pendant le développement (ex. identifiants Vagrant par défaut, clé Vagrant publique, détournements d’exploits eBPF/DirtyCOW) puis corrigés pour renforcer la validité. Les auteurs concluent que des runtimes à jour et correctement configurés restent une isolation adaptée aujourd’hui, tout en soulignant l’intérêt de ce type d’évaluation pour suivre l’évolution des risques.

• Vulnérabilités et surfaces testées (exemples cités) 🧪🐳:

  • Orchestration K8s: CVE‑2019‑1002101 (kubectl cp traversée de répertoires), CVE‑2020‑8558 (route_localnet), CRI‑O (CVE‑2022‑0811), RBAC trop permissif.
  • Runtime/OCI: docker.sock exposé, –privileged, CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_DAC_READ_SEARCH (technique « Shocker »), runc: CVE‑2019‑5736, CVE‑2024‑21626.
  • Noyau: Dirty COW (CVE‑2016‑5195), Dirty Pipe (CVE‑2022‑0847), eBPF (CVE‑2017‑16995), AF_PACKET (CVE‑2017‑7308), cgroup/release_agent (CVE‑2022‑0492), PID namespace avec capacités.

IOCs et TTPs:

  • IOCs: Aucun indicateur (IP/domaines/hashes) spécifique partagé.
  • TTPs (exemples):
    • Exploitation d’API/daemons exposés (Docker), élévation de privilèges noyau (eBPF, Dirty COW/Pipe, AF_PACKET), évasion de conteneur via capabilities excessives, montages hostPath et runc.
    • Abus des namespaces/cgroups (release_agent), contournements RBAC et traversées de répertoires (kubectl cp), accès localhost via route_localnet.

Conclusion: Il s’agit d’une publication de recherche présentant un benchmark et des résultats empiriques visant à quantifier la capacité des LLM à échapper à des bacs à sable conteneurisés et à fournir une base commune d’évaluation pour la communauté.

🧠 TTPs et IOCs détectés

TTP

Exploitation d’API/daemons exposés (Docker), élévation de privilèges noyau (eBPF, Dirty COW/Pipe, AF_PACKET), évasion de conteneur via capabilities excessives, montages hostPath et runc, abus des namespaces/cgroups (release_agent), contournements RBAC et traversées de répertoires (kubectl cp), accès localhost via route_localnet.

IOC

Aucun indicateur (IP/domaines/hashes) spécifique partagé.

🔗 Source originale : https://arxiv.org/abs/2603.02277