Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:50.427Z",
  "pubdate": "2026-09-26T14:16:50.427Z",
  "executiveSummary": "Grav versions prior to 2.0.25 contain a security vulnerability in bundled web server configuration samples that leads to unauthorized access to sensitive application data. The issue stems from case-sensitive matching rules for restricted directories and files in IIS (web.config) and lighttpd (lighttpd.conf) configurations. By manipulating the character casing of file paths in HTTP requests, an unauthenticated remote attacker can bypass access control mechanisms and retrieve sensitive configuration secrets or password hashes on systems where the underlying filesystem is case-insensitive, such as NTFS.\nThe vulnerability allows an attacker to bypass file-system-level restrictions intended to protect core application directories and sensitive configuration files. Successful exploitation results in the unauthorized disclosure of information, which could lead to full application compromise or remote code execution depending on the content of the exposed files. This is a critical security gap for Grav deployments running on affected web servers, as the configuration samples explicitly override secure defaults. The risk is particularly high for Windows-based IIS environments. Remediation requires an upgrade to Grav 2.0.25 and a manual update of the web server configuration files, as automated installers do not overwrite existing, potentially insecure configurations.",
  "technicalDetails": "The root cause of this vulnerability is the incorrect implementation of URL rewrite rules within the provided Grav web server configuration samples, specifically webserver-configs/web.config for IIS. The configuration files contain access-control deny rules for sensitive directories (e.g., /user/config, /system, /vendor) that explicitly set the 'ignoreCase' attribute to 'false' within the <match> element of the URL Rewrite module. This configuration overrides the standard IIS default behavior of case-insensitive matching.\nOn Windows systems utilizing NTFS, which is a case-insensitive filesystem, the IIS static file handler treats '/user/config/system.yaml' and '/USER/CONFIG/SYSTEM.YAML' as identical paths. Because the Rewrite rules are configured with ignoreCase='false', the regex engine fails to match the obfuscated case-varied path. Consequently, the request bypasses the security filter, and the IIS static file handler proceeds to serve the requested resource directly to the client.\nAn unauthenticated attacker can exploit this by injecting requests with varied casing (e.g., /user/CONFIG/system.YAML). If the server is configured to serve the file extension (e.g., .json), the contents are returned to the attacker. While .yaml and .yml files may return an HTTP 404.3 error on stock IIS instances due to the absence of specific MIME mappings, any custom configuration or alternate file extensions could lead to immediate disclosure of sensitive application secrets, password hashes, or infrastructure credentials.\nA secondary, though lower-risk, vulnerability exists in webserver-configs/lighttpd.conf. The rules governing sensitive directories, script extensions, and dotfiles lack the (?i) modifier necessary for case-insensitive matching. While lighttpd typically operates on case-sensitive filesystems, this configuration inconsistency represents a latent risk in specific deployment environments.\nThe vulnerability is persistent across Grav versions before 2.0.25. The attack requires no authentication or special privileges. The impact is limited only by the web server's ability to serve the requested file type. Crucially, the upgrade process for Grav does not automatically propagate these fixes to existing web server configurations. Operators must manually replace their current 'web.config' or 'lighttpd.conf' files with the corrected versions provided in the 2.0.25 release package to eliminate the bypass vector."
}