top of page
Rechercher

Double faille critique dans FortiSandbox — RCE non authentifié et bypass d'authentification

  • Photo du rédacteur: Loïc Castel
    Loïc Castel
  • il y a 6 jours
  • 7 min de lecture

FortiSandbox, la solution de bac à sable de Fortinet au cœur de la Security Fabric, est affectée par deux vulnérabilités critiques (CVSS 9.1) permettant à un attaquant non authentifié d'exécuter du code arbitraire en root et de contourner l'authentification via l'API JRPC. Les correctifs ont été publiés le 14 avril 2026 dans le cadre du Patch Tuesday Fortinet, accompagnés d'un PoC public déjà diffusé sur GitHub pour la première faille.


Ces deux CVE (CVE-2026-39808 et CVE-2026-39813) touchent un composant particulièrement sensible : l'appliance censée analyser les fichiers malveillants pour le reste du SI. Une compromission du sandbox permet à un attaquant de forger des verdicts « clean » sur des samples malveillants, empoisonnant l'ensemble de la chaîne de confiance Fortinet (FortiGate, FortiMail, FortiClient, FortiEDR, FortiSIEM).


Synthèse

  • CVE-2026-39808 : injection de commandes OS (CWE-78) dans l'API FortiSandbox, exploitable via une simple requête HTTP avec le caractère pipe | dans un paramètre GET. RCE non authentifié en root.

  • CVE-2026-39813 : path traversal ../filedir (CWE-24) dans l'API JRPC de FortiSandbox, permettant bypass d'authentification et escalade de privilèges sans credentials.

  • Versions affectées : FortiSandbox 4.4.0 → 4.4.8 (les deux CVE), 5.0.0 → 5.0.5 (CVE-2026-39813), plus FortiSandbox PaaS jusqu'à 23.4.4374.

  • Un PoC public est disponible sur GitHub pour CVE-2026-39808 (Samuel de Lucas Maroto, KPMG Spain) — exploitable en une seule commande curl.

  • Pas d'exploitation in-the-wild confirmée au moment de la publication, mais la fenêtre se referme vite : Fortinet est une cible historique des groupes ransomware et APT.

  • Correctifs : upgrade vers 4.4.9 ou 5.0.6.


Références


Chronologie et contexte

Fortinet a publié ses avis de sécurité FG-IR-26-100 et FG-IR-26-112 le 14 avril 2026, dans une vague d'une dizaine de CVE couvrant FortiSandbox, FortiOS, FortiAnalyzer et FortiManager. Les deux vulnérabilités FortiSandbox se démarquent par leur score CVSS identique de 9.1 (le NVD estime même CVE-2026-39813 à 9.8), leur vecteur réseau, l'absence d'authentification requise et la faible complexité d'exploitation.


Moins de 24 heures après la publication, un PoC pour CVE-2026-39808 a été diffusé sur GitHub par Samuel de Lucas Maroto (https://github.com/samu-delucas/CVE-2026-39808), l'auteur même de la découverte. Le PoC tient en une seule commande curl et ne nécessite aucune connaissance préalable de la cible au-delà de son URL. La seconde vulnérabilité (CVE-2026-39813) a été trouvée en interne par Loic Pantano, membre du Fortinet PSIRT.


Périmètre et versions impactées

CVE

Produit

Versions vulnérables

Version corrigée

CVE-2026-39808

FortiSandbox

4.4.0 → 4.4.8

4.4.9

CVE-2026-39808

FortiSandbox PaaS

≤ 23.4.4374

CVE-2026-39813

FortiSandbox

4.4.0 → 4.4.8

4.4.9

CVE-2026-39813

FortiSandbox

5.0.0 → 5.0.5

5.0.6


FortiSandbox étant typiquement déployé derrière le périmètre, le vecteur d'exploitation dépend du niveau d'exposition de l'interface de management — mais les scans Shodan/Censys montrent régulièrement des instances exposées à Internet, notamment sur les ports 443, 514, 541.


Rappel : comment fonctionne FortiSandbox

FortiSandbox est la solution de dynamic malware analysis de Fortinet. Son rôle dans la Security Fabric :


  1. Ingestion : fichiers et URLs arrivent via API REST ou automatiquement depuis FortiGate (AV hold), FortiMail, FortiClient, FortiProxy, FortiWeb.

  2. Pré-filtrage : hash lookup FortiGuard, moteur AV statique, YARA, analyse structurelle (PE/ELF/PDF/Office).

  3. Détonation : les samples suspects sont exécutés dans des VMs instrumentées (Windows, Linux, parfois Android), avec tracer kernel-mode.

  4. Tracer-behavior : capture des syscalls, I/O fichiers/registre, process tree, traffic réseau, injections mémoire, persistence.

  5. Scoring et verdict : clean / low / medium / high / malicious, renvoyé via l'API JRPC aux autres produits Fortinet.

  6. Threat intel loop : IOCs remontés vers FortiAnalyzer/SIEM et partagés avec FortiGuard.


Les deux CVE touchent précisément les deux interfaces exposées : l'UI web d'admin/reporting pour CVE-2026-39808, et l'API JRPC de communication inter-produits pour CVE-2026-39813.


Détails techniques — CVE-2026-39808

La vulnérabilité réside dans l'endpoint /fortisandbox/job-detail/tracer-behavior, qui affiche les résultats de l'analyse comportementale d'un job de sandbox. Le paramètre GET jid (job ID) est attendu comme un entier pointant vers une analyse, mais est concaténé sans sanitisation dans un appel shell côté backend.


En injectant un caractère pipe | suivi d'une commande shell, l'attaquant obtient une exécution de code en root sur l'appliance, sans authentification. Le PoC publié sur GitHub repose sur une structure de requête de ce type :


GET /fortisandbox/job-detail/tracer-behavior?jid=1|<commande>


L'absence totale de prérequis (pas de compte, pas de token, pas de cookie) et la trivialité du payload en font un candidat idéal pour les campagnes de scan automatisé.




Détails techniques — CVE-2026-39813

La seconde faille concerne l'API JRPC (JSON-RPC), utilisée par les produits de la Security Fabric pour dialoguer avec FortiSandbox (envoi de samples, récupération de verdicts, synchronisation de threat intel). Un path traversal ../filedir dans cette API permet à un attaquant non authentifié :


  • de contourner le mécanisme d'authentification de l'API,

  • d'accéder à des fichiers ou ressources hors du scope prévu,

  • d'escalader ses privilèges sur l'appliance.


Aucun PoC public n'est disponible à ce jour, mais la combinaison path traversal couplée à API d'administration rend l'ingénierie inverse du patch particulièrement attractive pour les acteurs malveillants. Fortinet n'a pas publié de détails sur le vecteur d'attaque précis, laissant aux chercheurs (et aux attaquants) le soin d'identifier les endpoints JRPC vulnérables par diff de patch.


Impact pour les organisations

Contrairement à une CVE classique sur un service exposé, la compromission de FortiSandbox a un effet de levier important sur l'ensemble du SI :


  • Exfiltration des échantillons analysés : tous les malwares capturés par la Security Fabric transitent par le sandbox. Pour un attaquant étatique, c'est une mine de samples ciblés, parfois des 0-days non publiés.

  • Verdict forgery : un attaquant qui contrôle le sandbox peut forcer le retour de verdicts clean sur des fichiers malveillants. Résultat : AV bypass à l'échelle pour tous les FortiGate/FortiMail/FortiEDR qui consomment ces verdicts.

  • Poisoning d'IOC : les indicateurs remontés vers FortiAnalyzer/FortiSIEM deviennent faux, générant soit des faux positifs massifs, soit pire, un masquage d'activité malveillante réelle.

  • Pivot interne : FortiSandbox est généralement déployé dans un VLAN d'administration sécurité, avec des routes directes vers les autres appliances Fortinet. Le lateral movement vers le cœur de la défense périmétrique est immédiat.


FortiSandbox est un single point of trust de l'architecture Fortinet pouvant permettre le rebond vers le reste de l’architecture.


Détection et indicateurs de compromission

En l'absence de règles de détection officielles publiées par Fortinet au-delà de l'advisory, voici les axes de chasse à mettre en œuvre en priorité :


Analyse des journaux HTTP de l'interface web FortiSandbox :


  • Requêtes vers /fortisandbox/job-detail/tracer-behavior contenant les caractères |, ;, &, $(, ` dans le paramètre jid

  • jid avec valeur non numérique (le paramètre légitime est un entier)

  • User-Agent suspects (scripts automatisés, curl, python-requests) sur cet endpoint

  • Corrélation avec des IP non whitelistées sur l'interface de management


Analyse des logs de l'API JRPC :


  • Présence de séquences ../ dans les requêtes JRPC

  • Appels JRPC sans en-tête d'authentification valide aboutissant à des réponses non-erreur

  • Pics de trafic JRPC en dehors des fenêtres de synchronisation habituelles avec la Security Fabric


Au niveau système :


  • Identification de processus enfants anormaux de l'application web FortiSandbox (shells, outils système lancés par le contexte web)

  • Modifications de fichiers système en dehors des fenêtres de mise à jour

  • Connexions sortantes inhabituelles depuis l'appliance vers Internet (beacon C2)


Commande de vérification rapide de version (via CLI FortiSandbox) : get system status


Recommandations de sécurité

Patch immédiat : la seule mitigation complète est l'upgrade vers FortiSandbox 4.4.9 ou 5.0.6. Les deux CVE ne disposent d'aucun workaround officiel publié par Fortinet.


En attendant le patch — il est recommandé de réduire la surface d'attaque :

  • Isoler l'interface de management : FortiSandbox ne doit en aucun cas être exposé à Internet. Restriction stricte de l'accès à l'UI web et à l'API JRPC via ACL et segmentation réseau (VLAN dédié admin sécu).

  • Restriction par IP source : whitelist des IP des opérateurs et des appliances Fortinet autorisées à dialoguer avec FortiSandbox sur les ports JRPC.

  • WAF en coupure : si l'appliance doit rester accessible, un WAF peut filtrer les caractères shell (|, ;, &) dans les paramètres de l'endpoint tracer-behavior, et les séquences ../ dans les requêtes JRPC.

  • Revue des logs sur les 30 derniers jours minimum, en priorité sur les endpoints identifiés ci-dessus.


Recommandations opérationnelles pour les équipes sécurité

Les RSSI et équipes infrastructure devraient traiter ces CVE comme un incident de priorité élevée, en particulier dans les environnements régulés (OIV, OSE, secteurs soumis à NIS2 / DORA) où FortiSandbox est souvent un composant clé du dispositif de détection.


Côté SOC / Blue Team, un effort de chasse ciblée est à engager sur les logs des 90 derniers jours, même en l'absence d'IoC publics : la situation rend le scénario « exploitation silencieuse avant patch » plausible. Des règles Sigma/Nuclei devraient être déployées sur les endpoints identifiés, et les alertes de la Security Fabric revues pour détecter d'éventuelles anomalies de verdicts (taux de « clean » anormalement élevé sur des familles de samples connus).


En cas d’incident avéré (https://www.safercy.com/reponse-a-incident), il est crucial de prévoir un playbook spécifique FortiSandbox : 

  • isolement réseau de l'appliance suspectée

  • export des journaux réseau

  • capture mémoire et disque avant toute action (analyse forensique)

  • rotation complète des secrets exposés (certificats, API keys partagées avec la Fabric)

  • vérification d'intégrité des binaires FortiSandbox via les hashes officiels Fortinet

  • revue a posteriori des verdicts rendus par l'appliance sur la période suspecte.


Enfin, les équipes pentest (https://www.safercy.com/pentest-tests-d-intrusion) devraient systématiquement intégrer la vérification de version FortiSandbox dans leurs missions d'audit interne, ainsi qu'un test de ségrégation réseau de l'interface de management.


Conclusion

CVE-2026-39808 et CVE-2026-39813 illustrent un pattern désormais familier dans l'écosystème Fortinet : des vulnérabilités critiques non authentifiées sur des composants d'infrastructure de sécurité, avec un PoC public rapidement disponible et une fenêtre d'exploitation avant patch qui se mesure en jours plutôt qu'en semaines ou mois.


FortiSandbox est un composant de confiance sur lequel repose la détection de menaces de tout le périmètre Fortinet. Une compromission ne se limite pas à la perte de l'appliance — elle invalide la chaîne de décision de l'ensemble de la Security Fabric. À ce titre, ces deux CVE doivent être traitées avec la même priorité qu'un RCE critique sur un composant cœur du SI, et non comme une simple vulnérabilité de plus dans le flux mensuel.


 
 
bottom of page