CVE-2026-72911

CVE-2026-72911 is a template injection vulnerability in ERPNext's Statement of Accounts feature that allows authenticated users to achieve remote code execution through the render_template path. The vulnerability lives in the subject, body, and pdf_name fields processed by the process_statement_of_accounts doctype — standard business functionality, not a hidden admin endpoint. What makes this severe: the render_template function injects frappe.utils into Jinja2 template globals by default. This module exposes file I/O helpers, subprocess calls, and the entire frappe.db API. An authenticated user with any standard operational role can trigger the Statement of Accounts rendering and inject payloads through template variables, executing arbitrary commands on the host. The CVSS 9.9 rating reflects that this is not a privilege-escalation path in practice. ERPNext's role system typically grants the relevant permissions to virtually all authenticated users — the "common operational role" framing in the CVE description substantially understates the actual attack surface. For most deployments, this vulnerability is effectively reachable by any user who can log in, which is often the entire organization plus external customers in B2B setups. The patch (versions 15.118.0 and 16.29.0) addresses the specific render_template call in this doctype. What is not yet clear from public disclosure is whether the fix was surgical — removing dangerous functions only from this specific template call — or architectural, redesigning render_template to stop injecting frappe.utils into globals by default. This distinction matters enormously for prioritizing further action. If the fix was surgical, other doctypes using the same render_template pattern with the same globals may remain vulnerable. Immediate actions: First, verify your ERPNext version and apply the patch if not already done — this is a high-priority update regardless of other hardening. Second, audit your custom doctypes and apps for any render_template calls that accept user-controlled input and may be exposing the same globals. Search for patterns like frappe.render_template in your codebase and review whether the context being passed includes frappe.utils or other sensitive modules. Third, treat the Statement of Accounts endpoint as a high-risk surface until you confirm the patch scope — consider rate-limiting or additional access controls on that route as a defense-in-depth measure while auditing continues. Finally, review user role assignments: if any roles can access the Statement of Accounts feature, those users have RCE capability through this vector — this may expand your incident response scope significantly. The underlying design question is broader than this CVE: any render_template call that exposes frappe.utils to user-influenced templates represents the same risk. ERPNext deployments should treat template rendering as a high-security boundary and audit where this pattern exists in both core and custom code.

Reviewed through automated stages and approved by a human before publication.