CVE-2026-78204 in Ghostwriter
Summary
by MITRE • 08/24/2026
Ghostwriter through 7.2.6 does not apply per-object authorization on its report template lint endpoints. RoleBasedAccessControlMixin.test_func returns only request.user.is_active unless a view overrides it, and neither the endpoint that lints a report template nor the endpoint that returns stored lint results provides an override, so each resolves a ReportTemplate from a caller-supplied primary key with no ownership or client-scope check. Any authenticated account can therefore lint an arbitrary template, which overwrites that template's stored lint result, and can read the returned findings, which enumerate the template's variable names and template-engine errors and so disclose its structure. This is distinct from the template swap path: that endpoint authorizes the report but omits the per-template check, whereas these endpoints omit authorization entirely and remain unfixed.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in Ghostwriter versions through 7.2.6 represents a critical failure in access control mechanisms within its reporting subsystem. Specifically, the application fails to enforce per-object authorization on two distinct API endpoints: one responsible for linting report templates and another that retrieves stored lint results. This flaw stems from an incomplete implementation of role-based access controls where the underlying mixin, RoleBasedAccessControlMixin.test_func, defaults to a generic check that only verifies if the request user is active. It does not perform any validation regarding whether the authenticated user has ownership or scope over the specific resource being accessed unless explicitly overridden by the view logic. In this case, neither the linting endpoint nor the result retrieval endpoint provides such an override, leaving them vulnerable to unauthorized access and manipulation.
From a technical perspective, the exploitation of this vulnerability allows any authenticated account to interact with arbitrary report templates identified by their primary keys supplied in the request parameters. When a user submits a template for linting via the affected endpoint, the system processes the input without verifying if the submitting user owns that specific template or has permission to modify it. Consequently, an attacker can overwrite the stored lint results of any other user's template. Furthermore, by querying the endpoint that returns these stored lint findings, an authenticated but unauthorized actor can read sensitive structural information about another user’s report templates. The returned data includes variable names and template-engine errors, which effectively disclose the internal structure and logic of the target application's reporting mechanisms.
The operational impact of this vulnerability is significant as it compromises both the integrity and confidentiality of the system's reporting assets. Integrity is compromised because an attacker can inject malformed or malicious content into a victim’s report template by triggering the linting process, potentially leading to service disruption or unexpected behavior when reports are generated. Confidentiality is breached because the enumeration of variable names and engine errors provides attackers with valuable intelligence about how the application constructs reports. This information can be leveraged in subsequent attacks, such as server-side template injection or other logic-based exploits that rely on understanding the specific variables and error handling mechanisms present in the templates.
This vulnerability aligns with CWE-284, Improper Access Control, specifically reflecting a failure to enforce proper authorization checks for individual resources rather than just general user roles. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, as it relies on valid authentication credentials but abuses the lack of granular permissions to perform unauthorized actions. The distinction between this flaw and other known issues in Ghostwriter is notable; while a previous vulnerability involved template swapping where authorization was applied at the report level but omitted for individual templates, these linting endpoints completely omit any form of per-object authorization check. This oversight remains unfixed in version 7.2.6, highlighting a systemic gap in how resource-level permissions are validated across different modules of the application.
To mitigate this vulnerability, developers must implement strict object-level access control checks on both the report template linting endpoint and the stored lint results retrieval endpoint. The RoleBasedAccessControlMixin should be overridden or extended to ensure that every request verifies whether the requesting user is the owner of the specific ReportTemplate instance identified by the primary key in the URL parameters. Additionally, implementing a deny-by-default policy for any resource access not explicitly permitted can prevent similar oversights in future development cycles. Regular security audits focusing on API endpoint authorization logic are recommended to ensure that all data manipulation and retrieval operations adhere to the principle of least privilege.