CVE-2026-100669 in Grav
Résumé
par VulDB • 26/09/2026
Grav avant la version 2.0.25 livre des exemples de configuration de serveur Web dont les règles d'interdiction du contrôle d'accès sont sensibles à la casse. Dans webserver-configs/web.config (IIS), chaque règle deny (user_sensitive_folders, user_accounts, user_data, user_error_redirect, user_pages, system, vendor, ignore_folders) définit ignoreCase="false" sur son élément URL Rewrite <match>, remplaçant ainsi le paramètre par défaut de IIS qui est ignoreCase="true". Étant donné qu'il s'agit de correspondances de réécriture et non d'éléments <requestFiltering>, il n'y a pas de repli insensible à la casse. Sur un système IIS fonctionnant sur NTFS insensible à la casse, un attaquant distant non authentifié peut modifier la casse du nom d'un dossier ou de l'extension d'un fichier (par exemple GET /user/CONFIG/system.YAML) afin qu'aucune règle deny ne corresponde et que le gestionnaire de fichiers statiques IIS résolve et renvoie le fichier sous-jacent, divulguant ainsi des données sensibles telles que les secrets de configuration ou les hachages de mots de passe des comptes. Le fait qu'un fichier contourné soit effectivement renvoyé dépend de l'enregistrement MIME : .json est servi par défaut, tandis que .yaml/.yml retournent un code HTTP 404.3 sur une installation standard d'IIS à moins qu'une correspondance MIME YAML n'ait été ajoutée. La même classe de vulnérabilité existe dans le fichier webserver-configs/lighttpd.conf inclus, dont les règles user/(config|env), directory, script-extension, root-file et dotfile manquent du modificateur (?i), bien que ce soit un risque moindre car lighttpd s'exécute généralement sur des systèmes de fichiers sensibles à la casse. Les déploiements servis par Apache (.htaccess), nginx, Caddy ou le serveur intégré PHP ne sont pas affectés. Le problème est corrigé dans la version 2.0.25 ; comme l'installateur .htaccess heal n'affecte ni web.config ni lighttpd.conf, les opérateurs doivent recopier manuellement les fichiers d'exemple corrigés après la mise à niveau.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.