CVE-2026-26083 : RCE non-auth FortiSandbox via Web UI (CVSS 9.1)

Les faits

Fortinet a publié le 14 mai 2026 un advisory PSIRT classifiant comme critique une vulnérabilité affectant la solution d'analyse comportementale FortiSandbox. Référencée CVE-2026-26083 et notée CVSS 9.1 (vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), la faille est un défaut d'autorisation manquante (CWE-862) qui permet à un attaquant distant non authentifié d'envoyer des requêtes HTTP forgées vers le Web UI et d'obtenir une exécution de code ou de commandes sur l'appliance.

FortiSandbox est l'appliance de sandboxing déployée en complément des firewalls FortiGate et des passerelles de messagerie FortiMail pour exécuter dynamiquement les fichiers suspects dans un environnement isolé. Elle agit comme un nœud central de la chaîne de détection, recevant les charges utiles depuis l'ensemble du périmètre Fortinet. Une compromission de FortiSandbox équivaut à neutraliser la couche d'analyse comportementale et, plus grave encore, à offrir à l'attaquant un point d'observation privilégié sur tous les fichiers que l'organisation considère suffisamment douteux pour être inspectés.

Le détail technique communiqué par Fortinet reste volontairement succinct, conformément à la politique habituelle du PSIRT : la racine du bug est une vérification d'autorisation manquante sur un endpoint REST exposé par l'interface d'administration HTTPS. Les chercheurs externes contactés par SecurityWeek indiquent que la faille permettrait de déclencher un workflow privilégié — création d'utilisateur administrateur, exécution de script de diagnostic, ou injection de commandes via un paramètre non sanitisé — sans présenter aucun jeton de session valide. Le vecteur d'attaque est donc strictement réseau, sans interaction utilisateur, ce qui justifie la note CVSS 9.1.

Les versions affectées couvrent l'intégralité des branches actuellement en support : FortiSandbox 5.0.0 à 5.0.1, 4.4.0 à 4.4.6, 4.2.0 à 4.2.7, ainsi que les éditions Cloud et PaaS hébergées par Fortinet jusqu'à la mise à jour orchestrée par l'éditeur. Les branches plus anciennes (4.0.x, 3.x) restent vulnérables et ne recevront pas de correctif, l'éditeur recommandant une migration vers une version supportée. Les builds correctifs sont 5.0.2, 4.4.7 et 4.2.8, publiés simultanément avec l'advisory.

Fortinet indique au moment de la publication ne pas avoir connaissance d'une exploitation active in-the-wild. Cette précision doit toutefois être nuancée : l'historique récent du PSIRT Fortinet montre régulièrement que des vulnérabilités annoncées comme non exploitées sont reprises dans des campagnes massives quelques jours après la publication de l'advisory, lorsque les chercheurs sont parvenus à reverser le patch et à reconstituer l'exploit. Le précédent de la CVE-2024-55591 (auth bypass FortiOS) ou plus récemment la CVE-2026-44277 documentée dans notre alerte FortiAuthenticator confirme cette dynamique.

Aucun proof-of-concept public n'a été publié à ce jour sur exploit-db, GitHub ou les flux Twitter spécialisés. Toutefois, la simplicité conceptuelle du bug — un endpoint REST manquant son middleware d'authentification — facilite la rétro-ingénierie. Les analystes de watchTowr et Horizon3 estiment qu'un exploit public pourrait apparaître dans un délai de 7 à 14 jours, en cohérence avec le rythme d'analyse observé sur les advisories Fortinet précédents.

Le contexte plus large est également défavorable : Fortinet a déjà fait l'objet de plusieurs incidents majeurs sur ses appliances exposées (FortiGate SSL VPN, FortiManager, FortiClient EMS), et le CERT-FR maintient depuis 2024 une consigne stricte de durcissement des accès administration pour l'ensemble de la gamme. L'avis PSIRT publié le 14 mai mentionne explicitement que cette vulnérabilité s'inscrit dans un lot de 11 bulletins publiés ce mois-ci, dont deux critiques et plusieurs autres notés high.

Côté exposition, les recherches Shodan et Censys identifient environ 14 000 instances FortiSandbox dont l'interface d'administration HTTPS est accessible depuis Internet à l'échelle mondiale, dont environ 350 hébergées en France. Ces chiffres sous-estiment la surface réelle car de nombreuses appliances sont exposées via VPN ou bastions, ce qui ne les rend pas moins vulnérables à un attaquant ayant déjà obtenu un point d'appui dans le réseau interne.

Impact et exposition

Toute organisation utilisant FortiSandbox dans une version antérieure aux builds correctifs et dont l'interface d'administration est joignable — directement depuis Internet ou via un pivot interne — doit considérer son appliance comme compromise par défaut jusqu'à preuve du contraire. La criticité est aggravée par le rôle central de FortiSandbox dans la chaîne de défense : un attaquant qui en prend le contrôle peut neutraliser silencieusement les verdicts de détection, exfiltrer les échantillons malveillants soumis par les autres modules Fortinet, et potentiellement injecter des configurations malveillantes vers les passerelles partenaires via les flux d'orchestration.

Les conditions d'exploitation sont minimales : une connectivité réseau vers le port HTTPS d'administration suffit. Aucune authentification, aucune interaction utilisateur, aucune configuration spécifique n'est requise. Les organisations exposant l'interface depuis Internet pour des raisons de gestion mutualisée (MSSP, prestataires de services managés) sont particulièrement vulnérables et doivent prioriser leur planning de patching.

L'exploitation active n'est pas confirmée par Fortinet à la date de l'advisory, mais la disponibilité simultanée des patches et le profil de la faille (RCE non-auth, criticité 9.1) en font une cible probable pour les courtiers d'accès initial dans les prochaines semaines. Les groupes ransomware spécialisés dans la compromission d'appliances de sécurité — Akira, Black Basta, RansomHub — surveillent activement les advisories Fortinet depuis 2024.

Les organisations soumises aux obligations LPM ou NIS2 doivent intégrer cette CVE dans leur cycle de patching prioritaire (SLA inférieur à 7 jours pour les vulnérabilités critiques sur les équipements de sécurité périmétrique). Une absence de patching documentée peut être qualifiée de manquement à l'obligation de moyens en cas d'incident.

Recommandations immédiates

• Appliquer immédiatement la mise à jour vers FortiSandbox 5.0.2, 4.4.7 ou 4.2.8 selon la branche déployée — advisory Fortinet PSIRT FG-IR-26-XXX du 14 mai 2026.
• Si le patching n'est pas possible sous 48 heures, restreindre l'accès à l'interface d'administration aux IP de confiance via Local-In Policy ou ACL upstream, et bloquer tout accès depuis Internet.
• Activer la journalisation détaillée des accès Web UI et exporter les logs vers un SIEM externe pour préserver la chaîne de preuve en cas de compromission ultérieure.
• Rechercher dans les logs des 30 derniers jours les requêtes HTTP non authentifiées vers les endpoints REST de l'administration — toute requête anormale doit déclencher une analyse approfondie.
• Régénérer après patching l'ensemble des credentials administrateurs, des clés API et des certificats utilisés par FortiSandbox pour l'intégration avec les autres modules Fortinet.
• Vérifier l'intégrité des verdicts d'analyse récents et reconsidérer les fichiers ayant transité par FortiSandbox entre le 1er mai et la date de mise à jour effective.