CVE-2026-92916 in Grav
Summary
by MITRE • 09/17/2026
Grav is a flat-file CMS. In Grav 1.7.0 through 1.7.53.2 and 2.0.0 through 2.0.21, when the debugger is enabled (system.debugger.enabled: true, which is not the default), the Clockwork profiler endpoint is exposed without authentication: InitializeProcessor::handleDebuggerRequest() intercepts any path containing /__clockwork/ during bootstrap and passes it to Debugger::debuggerRequest(), which performs no user lookup, IP restriction, or Clockwork authenticator check, and also supports anonymous pagination over the entire stored history. With the shipped censored: false default, each stored record contains raw request cookies (including Grav's session cookie, whose value is the PHP session id, allowing an attacker to resume another user's session, including an authenticated admin's), the full parsed request body (Grav's login form posts data[username]/data[password], so passwords are stored in plaintext because Clockwork's password filter only inspects top-level keys), and the site's entire system and plugin configuration, including operator-saved secrets such as SMTP credentials, third-party API keys, and licence keys. Authorization and X-API-Token headers are stored even when censored: true. On Grav 2.0, setting provider: debugbar does not avoid the issue because Grav forces the Clockwork provider for requests preferring a JSON response. The issue is fixed in 1.7.53.4 and 2.0.22, which restrict /__clockwork/ to server-local requests or requests presenting the new system.debugger.token secret and strip cookies and credential headers from stored records. Workarounds include setting debugger.enabled: false or blocking /__clockwork/ at the web server or CDN.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in Grav, a popular flat-file content management system, represents a critical failure in access control and data sanitization within its debugging infrastructure. Specifically affecting versions 1.7.0 through 1.7.53.2 and 2.0.0 through 2.0.21, this flaw allows unauthenticated attackers to access sensitive internal profiling data when the system debugger is enabled. Although enabling the debugger is not a default configuration setting, it is frequently utilized by administrators during development or troubleshooting phases. The core technical issue lies in the InitializeProcessor::handleDebuggerRequest() method, which intercepts any request path containing /__clockwork/ during the bootstrap process and forwards it to Debugger::debuggerRequest(). This function fails to perform essential security checks such as user authentication lookup, IP address restriction, or verification of a Clockwork authenticator token. Consequently, the endpoint remains publicly accessible to anyone who knows its location, provided they can reach the server network.
The operational impact of this vulnerability is severe due to the nature and volume of data exposed by the Clockwork profiler. By default, Grav stores request history with censored: false enabled, meaning that raw, unsanitized data from every intercepted HTTP request is persisted in local storage files accessible via the debugger endpoint. This includes full request cookies, which contain Grav's session cookie holding the PHP session identifier. An attacker can extract this session ID to perform a Session Hijacking attack, effectively taking over an active user session without needing credentials. If the victim of the hijacked session holds administrative privileges, the attacker gains complete control over the CMS environment. Furthermore, because Grav’s login form posts data in a nested structure under keys like data[username] and data[password], Clockwork's default password filtering mechanism fails to detect these fields as sensitive since it only inspects top-level keys. As a result, plaintext passwords are stored alongside other request details, creating a direct path for credential theft via Credential Stuffing or brute-force attacks if the attacker obtains this database of historical requests.
Beyond authentication credentials, the vulnerability exposes comprehensive system configuration data that can facilitate further exploitation and lateral movement within an organization's infrastructure. The profiler stores complete copies of Grav’s system and plugin configurations, including operator-saved secrets such as SMTP email server credentials, third-party API keys for services like payment gateways or cloud storage, and software license keys. Even when the censored flag is set to true, authorization headers and X-API-Token values are still stored in plaintext because the sanitization logic does not adequately cover these specific header types. This leakage of sensitive configuration data aligns with CWE-798: Use of Hard-coded Credentials and CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. The ability to retrieve this information remotely allows attackers to map out the backend architecture, identify weak points in third-party integrations, and potentially compromise other systems that share these credentials or API keys.
The vulnerability persists across different profiler providers due to a specific implementation detail in Grav 2.0 where setting provider: debugbar does not avoid the issue because the system forces the Clockwork provider for requests preferring JSON responses. This design oversight ensures that the attack surface remains consistent regardless of the administrator's choice of debugging tool, provided the debugger is enabled and accepts JSON-formatted queries. The flaw is categorized under MITRE ATT&CK technique T1504: Web Framework, as it exploits a legitimate administrative interface for data exfiltration, and relates to CWE-287: Improper Authentication due to the lack of identity verification before serving sensitive internal state information.
Mitigation strategies focus on reducing the attack surface or restricting access to the vulnerable endpoint. The primary remediation is upgrading Grav to version 1.7.53.4 or later, where the /__clockwork/ path is restricted to server-local requests only or requires presentation of a new system.debugger.token secret for authentication. Additionally, these updated versions strip cookies and credential headers from stored records, preventing the leakage of session IDs and plaintext passwords. For environments unable to upgrade immediately, administrators should disable the debugger entirely by setting system.debugger.enabled to false in the configuration files. Alternatively, network-level controls can be implemented at the web server or CDN level to block external access to paths containing /__clockwork/, ensuring that even if the application logic remains flawed, the endpoint is not reachable from untrusted networks.