CVE-2026-100669 in Grav
Summary
by MITRE • 09/26/2026
Grav before 2.0.25 ships web server configuration samples whose access-control deny rules are matched case-sensitively. In webserver-configs/web.config (IIS), every deny rule (user_sensitive_folders, user_accounts, user_data, user_error_redirect, user_pages, system, vendor, ignore_folders) sets ignoreCase="false" on its URL Rewrite <match> element, overriding the IIS default of ignoreCase="true"; because these are rewrite matches rather than <requestFiltering> elements, there is no case-insensitive fallback. On IIS running over case-insensitive NTFS, an unauthenticated remote attacker can vary the case of a folder name or file extension (for example GET /user/CONFIG/system.YAML) so that no deny rule matches and the IIS static file handler resolves and returns the underlying file, disclosing sensitive data such as configuration secrets or account password hashes. Whether a bypassed file is actually returned depends on MIME registration: .json is served by default, while .yaml/.yml return HTTP 404.3 on a stock IIS unless a YAML MIME mapping has been added. The same class of gap exists in the bundled webserver-configs/lighttpd.conf, whose user/(config|env), directory, script-extension, root-file and dotfile rules lack the (?i) modifier, though it is lower risk because lighttpd typically runs on case-sensitive filesystems. Deployments served by Apache (.htaccess), nginx, Caddy, or the PHP built-in server are not affected. The issue is fixed in 2.0.25; because the .htaccess installer heal does not touch web.config or lighttpd.conf, operators must re-copy the corrected sample files after upgrading.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Grav versions prior to 2.0.25 stems from a misconfiguration in the bundled web server configuration samples, specifically affecting Internet Information Services and Lighttpd deployments. The core technical flaw lies in how access-control deny rules are defined within these configuration files. In the IIS web.config file, URL Rewrite match elements for sensitive directories such as user_sensitive_folders, user_accounts, system, vendor, and others explicitly set ignoreCase to false. This setting overrides the default behavior of IIS, which typically treats URLs case-insensitively due to its integration with NTFS filesystems that are inherently case-insensitive by default. Because these rules rely on URL Rewrite patterns rather than native request filtering mechanisms like <requestFiltering>, there is no fallback mechanism to enforce case-insensitivity if the rewrite rule fails to match. Consequently, an attacker can exploit this discrepancy by varying the capitalization of folder names or file extensions in their requests. For instance, a request targeting /user/CONFIG/system.YAML may bypass the deny rules designed to block access to system.yaml because the lowercase configuration does not match the case-sensitive pattern defined in the web.config file.
The operational impact of this vulnerability is significant for organizations running Grav on IIS with case-insensitive filesystems. An unauthenticated remote attacker can leverage this flaw to retrieve sensitive files that are intended to be protected from public access. These files often contain critical configuration secrets, database credentials, or account password hashes stored in YAML format. The actual disclosure of data depends heavily on the MIME type registration within the IIS environment. While standard file types like JSON might be served directly if accessed via a bypassed path, YAML and YML files typically return an HTTP 404.3 error indicating that access is forbidden by request filtering rules unless a specific MIME mapping for YAML has been manually configured in the server settings. This means that while the vulnerability exists, successful exploitation requires either a custom MIME configuration or reliance on other vector-based disclosures where the file content might be inferred through side channels or subsequent errors.
A similar but lower-risk issue exists within the bundled lighttpd.conf sample configuration. The rules governing access to user directories, environment files, script extensions, root files, and dotfiles lack the case-insensitive modifier (?i). However, this vulnerability is considered less critical because Lighttpd typically operates on Linux-based systems where filesystems are inherently case-sensitive. Therefore, an attacker would need precise knowledge of the exact casing used in the file system to successfully bypass these rules, making exploitation significantly more difficult compared to the IIS scenario. Deployments utilizing Apache with .htaccess files, nginx, Caddy, or the PHP built-in server remain unaffected by this specific issue as their respective configuration mechanisms handle case sensitivity differently and do not suffer from the same mismatch between web server logic and underlying filesystem behavior.
To mitigate this vulnerability, organizations must upgrade to Grav version 2.0.25 or later, which includes corrected sample configurations for both IIS and Lighttpd that properly enforce case-insensitive matching where appropriate. It is crucial to note that upgrading the application alone does not automatically fix existing deployments because the installer heal process does not overwrite manually edited or pre-existing web.config and lighttpd.conf files. System administrators must manually re-copy the corrected sample configuration files from the updated Grav installation into their respective server directories after performing the upgrade. This manual step ensures that the access-control rules are correctly aligned with the security requirements of the environment. From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and represents an attempt to bypass restrictions via case variation, which can be mapped to ATT&CK technique T1078 Valid Accounts if used in conjunction with credential theft or simply as a method for unauthorized data access under the broader category of Misconfiguration.