CVE-2026-82634 in Frappe
Summary
by MITRE • 08/30/2026
Frappe Framework development builds contain an authorization flaw in the render_jinja_template endpoint that allows low-privileged users to render arbitrary Jinja templates by supplying raw template strings. Attackers with print permission on any document can execute arbitrary SELECT statements against unrelated tables, including reading password hashes from the __Auth table.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/30/2026
The Frappe Framework development builds contain a critical authorization flaw within the render_jinja_template endpoint that fundamentally undermines access control mechanisms by allowing low-privileged users to bypass intended restrictions through raw template string injection. This vulnerability arises because the framework fails to adequately sanitize or restrict input passed to its Jinja2 templating engine during runtime execution in non-production environments, although such exposure can persist if development modes are inadvertently enabled on production systems. The core technical flaw lies in the lack of strict validation for user-supplied data before it is processed as a template context variable, enabling an attacker with minimal permissions, specifically print access to any document within the application, to inject arbitrary Jinja syntax that gets executed server-side rather than merely rendered statically.
From a technical perspective, this vulnerability facilitates Server-Side Template Injection (SSTI), which in the context of Frappe’s architecture translates directly into SQL injection capabilities due to how the framework integrates its ORM with the templating engine. By supplying carefully crafted raw template strings containing Jinja expressions that invoke Python functions or database query methods available within the global namespace, an attacker can execute arbitrary SELECT statements against unrelated tables in the underlying PostgreSQL or MariaDB database. This bypasses standard row-level security and permission checks because the execution occurs at a higher privilege level than the user’s assigned role permits, effectively elevating their capabilities from simple document viewing to full database interrogation without requiring authentication beyond basic print rights on any single object.
The operational impact of this vulnerability is severe, as it allows attackers with low-privileged accounts to exfiltrate sensitive data including password hashes stored in the __Auth table, session tokens, and other confidential business information residing in unrelated modules. This compromise undermines the confidentiality integrity of the entire application ecosystem since database credentials or hashed passwords can be further cracked offline to gain higher-level access. Furthermore, because Jinja2 execution environments often have access to Python’s built-in functions depending on configuration, this flaw could potentially lead to Remote Code Execution (RCE), allowing attackers to run arbitrary system commands and take complete control of the hosting server if additional safeguards are not in place.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code or Script commonly referred to as code injection, specifically manifesting through Server-Side Template Injection patterns documented under CWE-1386. In terms of offensive security frameworks, this attack vector corresponds to MITRE ATT&CK technique T1059 Command and Scripting Interpreter where Jinja expressions act as the scripting mechanism for database interaction, and potentially T1190 Exploit Public-Facing Application if exploited over network interfaces without prior authentication beyond basic document permissions. The exploitation path also relates to CWE-284 Improper Access Control since low-privileged users are able to perform actions reserved for administrators or higher-level roles through the abuse of template rendering logic.
Mitigation strategies must prioritize immediate remediation by ensuring that development builds and debug modes are strictly disabled in any environment exposed to external networks, as these modes often relax security constraints for developer convenience. Developers should implement strict allow-listing for Jinja2 globals and filters, disabling access to dangerous functions like config, eval, or exec within the template context. Additionally, input validation must be enforced at the API layer to reject raw template strings from untrusted sources, ensuring that only predefined safe templates are rendered based on explicit user permissions rather than dynamic string injection. Regular security audits of framework configurations and dependency updates are essential to maintain a secure posture against such logic-based exploitation techniques.