CVE-2026-37709 : RCE critique Snipe-IT via upload (9.8)

Les faits

La vulnérabilité CVE-2026-37709, divulguée publiquement le 7 mai 2026, affecte Snipe-IT, l''une des solutions open-source de gestion d''actifs informatiques les plus déployées dans les PME, les administrations et les laboratoires de recherche. Le projet, distribué par Grokability sous licence AGPL, totalise plusieurs dizaines de milliers d''installations actives à travers le monde, avec une présence particulièrement marquée dans les services IT cherchant une alternative à GLPI ou aux solutions propriétaires de type ServiceNow Asset Management. Sa surface fonctionnelle inclut l''inventaire matériel, la gestion des licences, le suivi des consommables et l''attribution d''actifs aux utilisateurs.

La faille porte un score CVSS 9.8, soit le maximum pour une RCE non authentifiée à fort impact. Sa classification CWE de référence est « Insecure Permissions », un terme générique qui recouvre ici un défaut de configuration des permissions appliquées aux fichiers uploadés via l''API. Le composant impliqué est précisément app/Http/Controllers/Api/UploadedFilesController.php, le contrôleur Laravel responsable de la réception et du stockage des fichiers téléversés par les clients de l''API Snipe-IT — typiquement des photos d''actifs, des justificatifs de licence ou des manuels constructeurs.

Le mécanisme d''exploitation suit un schéma connu dans les applications PHP qui acceptent des uploads sans isoler le répertoire de stockage du moteur d''exécution. Snipe-IT, en versions 8.4.0 et antérieures, écrit les fichiers téléversés dans un répertoire accessible depuis le contexte HTTP, sans vérifier strictement le type MIME, sans réécrire l''extension, et sans appliquer une politique d''exécution restrictive au niveau du serveur web. Un attaquant qui parvient à téléverser un fichier .php — par exemple en le renommant ou en exploitant une vérification trop permissive du type — peut ensuite l''invoquer directement via une URL HTTP, ce qui déclenche son exécution par PHP-FPM ou mod_php, et lui donne un shell distant avec les privilèges du processus web.

Le second pan du défaut est lié aux permissions filesystem appliquées par le contrôleur. Les fichiers déposés héritent de permissions trop ouvertes (typiquement 0664 ou 0666 selon l''umask du processus PHP), ce qui permet à un compte authentifié sur le serveur — ou à un autre processus partageant le même utilisateur — de modifier le fichier après upload. Combiné à la possibilité d''upload sans contrôle d''extension stricte, cela ouvre plusieurs scénarios d''escalade : déposer un fichier inoffensif puis l''écraser par du PHP, ou bien déposer directement une charge utile et l''invoquer.

L''avis de Snipe-IT ne mentionne pas d''exploitation active à la date de divulgation, mais TheHackerWire et plusieurs agrégateurs CVE ont confirmé la criticité. Aucun PoC public exhaustif n''est référencé sur Exploit-DB ou GitHub à ce jour, mais le commit correctif 676a9958, daté du 10 mars 2026, est public et consultable sur le dépôt Grokability/snipe-it. Tout opérateur compétent peut donc reconstruire l''attaque en analysant le diff entre la version vulnérable et la version corrigée, ce qui réduit drastiquement le délai entre divulgation et exploitation pratique.

La chronologie laisse à penser que la vulnérabilité a été corrigée silencieusement en mars 2026 dans la branche principale, puis publiée formellement avec un identifiant CVE deux mois plus tard, le 7 mai 2026. Cette pratique — fixer d''abord, communiquer ensuite — est courante dans les projets open-source pour donner aux utilisateurs un délai d''adoption avant l''exposition publique. Elle suppose toutefois que les opérateurs suivent activement les releases : les déploiements anciens, en versions 8.4.0 et antérieures, restent vulnérables tant qu''ils ne sont pas mis à jour, indépendamment de la date de divulgation.

La cause racine, sur le plan logiciel, est une défense en profondeur insuffisante. Une application web bien conçue qui accepte des uploads doit cumuler plusieurs barrières : validation stricte de l''extension à partir d''une liste blanche, validation du contenu via une bibliothèque de type magic-byte ou imagettype(), réécriture systématique du nom de fichier avec un identifiant aléatoire, stockage hors du document root du serveur web, et configuration explicite côté Apache/Nginx pour interdire l''exécution PHP dans le répertoire d''upload. Le correctif Snipe-IT renforce plusieurs de ces barrières, mais l''architecture de l''application — qui sert les fichiers uploadés via une URL publique — ne permet pas d''appliquer toutes les protections sans changements plus profonds.

L''exploitation pratique varie selon la configuration du serveur cible. Sur une stack LAMP classique avec mod_php et un répertoire uploads accessible directement, un fichier shell.php déposé est exécutable immédiatement par GET vers /uploads/shell.php. Sur une stack avec PHP-FPM et un .htaccess restrictif, l''exécution directe peut être bloquée mais d''autres voies existent : inclusion via une autre vulnérabilité, contournement de l''.htaccess par double extension (.php.jpg), ou exploitation de la confusion d''extension lorsque Snipe-IT est servi par un Nginx mal configuré qui passe les fichiers .php.X à PHP-FPM. La diversité des configurations rend l''évaluation du risque par installation un exercice à part entière.

Impact et exposition

Toute installation Snipe-IT en versions 8.4.0 ou antérieures est concernée. Comme la vulnérabilité touche le contrôleur d''upload, les déploiements qui désactivent les fonctionnalités de téléversement (via configuration applicative ou règles WAF) réduisent leur surface, mais la majorité des installations laissent ces routes ouvertes par défaut, car elles sont utilisées en quotidien par les administrateurs IT pour joindre des fichiers à chaque actif.

La condition d''exploitation principale dépend du niveau d''accès requis pour atteindre le contrôleur d''upload. Selon la configuration de Snipe-IT, l''API d''upload peut être ouverte à tout utilisateur authentifié — y compris des comptes en lecture seule selon le rôle attribué — ou restreinte aux administrateurs. Dans les deux cas, le risque interne est important : un employé malveillant ou un compte compromis suffit à obtenir un shell sur le serveur. Les installations qui n''appliquent pas d''authentification multi-facteurs ou qui acceptent les comptes locaux sans politique de mot de passe stricte sont particulièrement exposées.

L''exposition externe dépend de la mise en accès Internet de l''instance. De nombreux Snipe-IT sont déployés en SaaS interne derrière un VPN ou un SSO d''entreprise, ce qui limite la surface au périmètre d''accès employé. D''autres, notamment dans les PME et les ESN, sont exposés directement sur Internet pour permettre aux techniciens itinérants de scanner et d''enregistrer du matériel depuis le terrain. Ces dernières instances doivent être patchées en priorité absolue, car elles cumulent la criticité de la faille avec une exposition au scan opportuniste.

Recommandations immédiates

• Mettre à jour Snipe-IT vers une version postérieure au commit 676a9958 du 10 mars 2026, soit toute release publiée après cette date. Vérifier le tag exact dans le changelog du projet.
• Vérifier le contenu du répertoire de stockage des uploads pour détecter la présence de fichiers .php, .phtml, .phar ou tout fichier avec une double extension (par exemple image.php.jpg). Tout fichier suspect doit être quarantainé et l''origine de l''upload investiguée dans les logs d''accès.
• Configurer le serveur web pour interdire explicitement l''exécution de fichiers PHP dans le répertoire d''upload. Sur Apache, utiliser une directive « php_admin_flag engine off » dans une ou un .htaccess.
• Restreindre les permissions filesystem du répertoire d''upload à 0750 et propriétaire user web, sans accès en écriture pour les autres comptes système.
• Auditer les comptes Snipe-IT, désactiver les comptes inactifs et appliquer une politique de mot de passe robuste, voire activer le 2FA si la version installée le supporte.