CVE-2026-62673: Security Bypass in Grav CMS via Case-Sensitivity Mismatch

Grav is an open-source, flat-file content management system (CMS) constructed on a modern PHP architecture. In a flat-file CMS model, administrative profiles, database records, and site configurations are stored directly in structured files (such as YAML, JSON, or Markdown) within the local directory structure. Because Grav does not use a relational database, securing these configuration directories at the web server level is critical to protecting the overall integrity of the application.

To restrict unauthorized read access to sensitive installation directories, Grav ships with a preconfigured Apache .htaccess file. This file contains rewrite patterns that instruct Apache to deny direct HTTP requests targeting critical directories. These restricted zones include the application core, cache directories, and the user folder, which houses local user configurations and credentials.

However, in configurations where Grav is deployed on operating systems or file storage mechanisms that use a case-insensitive filesystem, a logical mismatch emerges. This mismatch occurs because the default configuration rules in Apache are evaluated case-sensitively, while the underlying storage engine matches requests case-insensitively. This vulnerability allows attackers to bypass the application security policies and directly access secret configurations.

The underlying flaw belongs to the CWE-178 category (Improper Handling of Case Sensitivity). Under standard configurations, Apache's mod_rewrite processing engine handles regular expression patterns in a case-sensitive manner unless explicitly configured otherwise. For a pattern to cover all potential casing permutations, the developer must append the [NC] (No Case) flag to the rewrite rule directive.

In Grav deployments prior to version 2.0.4, multiple defensive rules within .htaccess and webserver-configs/htaccess.txt omitted the [NC] flag. For instance, the rule restricting direct web access to sensitive user configuration folders was defined strictly with lowercase patterns. A representative rule looked like RewriteRule ^(user)/(accounts|config|data|env)/(.*) error [F] which explicitly matches only the exact lowercase string 'user'.

When this configuration is run on environments with case-insensitive storage backends, such as macOS with APFS, Windows with NTFS, or Docker setups mounting host folders from these operating systems, a discrepancy occurs. Although Apache treats /user/ and /User/ as distinct strings during the evaluation of RewriteRule, the filesystem treats them as identical paths when retrieving the target resource.

Consequently, an unauthenticated request targeting /User/accounts/admin.yaml fails to trigger the case-sensitive block for the lowercase word user. Apache permits the request to pass through its rewrite pipeline. The OS file handler then processes the directory path /User/accounts/admin.yaml, resolves it to the physical file user/accounts/admin.yaml on disk, and serves the raw contents back to the requester.

To illustrate this gap, we can analyze the rewrite rule differences before and after the security patch was applied. The following block contrasts the vulnerable and corrected implementations of the .htaccess configuration file:

# Vulnerable implementation prior to 2.0.4
# The absence of the NC flag makes these rules strictly case-sensitive
RewriteRule ^(user)/(accounts|config|data|env)/(.*) error [F]
RewriteRule ^(user)/(.*)\.(txt|md|json|yaml|yml|php)$ error [F]
 
# Patched implementation in 2.0.4
# The addition of the NC flag forces case-insensitive matching
RewriteRule ^(user)/(accounts|config|data|env)/(.*) error [F,NC]
RewriteRule ^(user)/(.*)\.(txt|md|json|yaml|yml|php)$ error [F,NC]

The fix commits applied by developer Andy Miller in commit 8c9d1e7b6fd66ecea80a4bc3783fd41d36e22fb1 demonstrate that this issue spanned multiple restrictive security rules. Security boundaries were bypassed not only for directory names but also for file extension filters.

For example, rules blocking direct retrieval of configuration files with specific extensions were bypassed if an attacker modified the extension casing in the HTTP request. A request targeting user/config/security.YAML evaded the lowercase-only matching group \.(txt|md|json|yaml|yml|php)$ but still successfully resolved to the configuration file on disk. The correction of this flaw requires appending ,NC to the rewrite rules, transforming the flags from [F] (Forbidden) to [F,NC] (Forbidden, No Case).

Exploitation of CVE-2026-62673 is straightforward and can be executed via command-line utilities. An attacker must first identify a target running an unpatched version of Grav CMS on a case-insensitive platform. No authentication or application-level privileges are necessary to perform this attack.

To bypass directory-level filtering, the attacker modifies the path casing within the HTTP request. Sending a standard GET request to /User/accounts/admin.yaml prompts the server to evaluate the request against .htaccess. Because the path starts with an uppercase 'U', it bypasses the case-sensitive rewrite block. The filesystem maps /User/ directly to the actual /user/ folder and returns the file containing administrative password hashes.

# Example request to bypass directory restrictions
curl -i "http://example.com/User/accounts/admin.yaml"

To bypass extension-level constraints, the attacker alters the casing of the target extension. Requesting /user/config/security.YAML bypasses the lowercase configuration pattern. Since the filesystem matches the extension case-sensitively, it retrieves the security file, exposing critical data like the system-wide CSRF salt. The following diagram illustrates the lifecycle of this bypass vector:

The security impact of successful exploitation is severe. Because Grav is a flat-file CMS, administrative passwords, account credentials, and system secrets are not stored behind database-level isolation. They reside directly on the filesystem in plain-text or easily hashable YAML structures.

Retrieval of the user/accounts/admin.yaml file exposes the Bcrypt-hashed password of the administrative user, along with configuration attributes and registration details. A remote attacker can capture this hash and attempt offline brute-force attacks to crack the password. This compromises the overall control of the CMS administrative panel.

Additionally, accessing user/config/security.yaml exposes system secrets, including the application salt. Attackers can leverage the salt to forge sessions, bypass token verification mechanisms, or build exploits for other parts of the system. This chain of access facilitates subsequent attacks, elevating a single information disclosure into full application takeover.

The primary remediation path is upgrading the Grav installation to version 2.0.4 or higher. This release integrates the necessary case-insensitive flag controls into the default .htaccess templates. Administrators should verify their current version using the Grav command-line interface or the administrative backend dashboard.

For systems where an immediate upgrade is not feasible, administrators must manually edit the root .htaccess and webserver-configs/htaccess.txt files. Each rewrite rule within the designated security block must be updated to append the ,NC parameter to the existing configuration flags, changing [F] to [F,NC].

Additionally, hosting environments can transition to case-sensitive filesystems to mitigate this entire class of bugs. On Linux-based environments, ensuring Docker volumes are mounted on native ext4 filesystems rather than Windows or macOS host shares removes the discrepancy. This strategy aligns the filesystem and web server path handling logic.