Description

The Comments plugin (getgrav/grav-plugin-comments) for Grav CMS through version 1.2.10 registers an admin handler that returns comment data as JSON without any authentication check. The handler branches on isAdmin(), which only indicates that the admin service is registered on the current route rather than that the visitor is authenticated, and it echoes the JSON and calls exit() during the plugins stage, before the classic Admin plugin would render its login screen. On a site using the classic Admin plugin with Comments enabled (the default), an unauthenticated remote attacker can request /admin/comments/page:<n> (e.g. page:0.001) and retrieve every comment from the last 7 days, including each commenter's email address and the absolute server filesystem path of the data file. Sites running the Grav 2.0 Admin Next stack (admin2 + api) are not affected via this path. The issue is fixed in 1.2.11, which requires an authenticated user with admin.comments or admin.super and removes the absolute filePath from the response.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:50.970Z",
  "pubdate": "2026-09-26T14:16:50.970Z",
  "executiveSummary": "The Grav CMS Comments plugin (through version 1.2.10) contains a critical information disclosure vulnerability. The issue stems from an improper authentication check within the plugin's admin handler, which improperly validates visitor authorization.\nBy failing to verify user sessions, the handler allows unauthenticated remote attackers to query internal comment data. The exposure includes personally identifiable information (PII) such as commenter email addresses, as well as sensitive system metadata, specifically the absolute filesystem paths where comment data is stored on the server.\nThis vulnerability poses a significant risk to site privacy and operational security. An attacker can mass-harvest user data and leverage the disclosure of absolute server paths to assist in reconnaissance for further exploits, such as local file inclusion or targeted path traversal attacks.\nThe vulnerability affects installations using the classic Grav Admin plugin stack. Systems utilizing the Grav 2.0 Admin Next stack are not susceptible to this specific vector. Users are strongly advised to update the Comments plugin to version 1.2.11 or later to enforce proper access control mechanisms and redact sensitive path information.",
  "technicalDetails": "The root cause of this vulnerability is an insecure implementation of access control within the Grav Comments plugin's admin handler. The handler utilizes an isAdmin() check that merely validates whether the admin service is registered on the current route, rather than verifying the authentication status or authorization level of the requesting user.\nDuring the plugin execution stage, specifically before the classic Admin plugin invokes the authentication/login gate, the vulnerable handler processes the incoming request. Because the check does not validate a session or security token, it proceeds to echo JSON data and terminates execution via an exit() call, effectively bypassing all authentication requirements.\nAn attacker can exploit this by sending a crafted HTTP request to the /admin/comments/page:<n> endpoint. Because the handler logic ignores the authentication context, it retrieves and returns all comments generated within the last 7 days. The returned JSON blob contains sensitive data, including the commenter's email address and the server's absolute filesystem path for the associated data file.\nThe attack flow is straightforward: 1) The attacker identifies a target site running a vulnerable version of the Comments plugin. 2) The attacker crafts an HTTP request to the /admin/comments/ endpoint with a page parameter. 3) The server, failing to verify the identity of the requester, executes the handler logic. 4) The plugin queries the comment repository and returns the data in a JSON response. 5) The attacker captures this response to extract user PII and server-side structural information.\nThis vulnerability is particularly dangerous because the exposure of absolute server paths provides an attacker with critical internal system knowledge. This information can be leveraged in subsequent attacks to identify the file structure, facilitating more complex exploits targeting the web server's environment. The issue is resolved in version 1.2.11 by implementing strict authentication requirements, ensuring that only users with admin.comments or admin.super privileges can access the endpoint, and by sanitizing the response to remove absolute filesystem paths."
}