Frappe ERPNext server-side template injection enables arbitrary code execution

ERPNext is a free and open source Enterprise Resource Planning tool. Prior to 15.118.0 and 16.29.0, the validate_template and render_template calls in erpnext/accounts/doctype/process_statement_of_accounts/process_statement_of_accounts.py render subject, body, and pdf_name fields with unrestricted globals including frappe.utils, allowing an authenticated user with a common operational role to inject template expressions, execute arbitrary server-side code, and read data across the application. This issue is fixed in versions 15.118.0 and 16.29.0.

• Frappe ERPNext branch 15: affected versions are < 15.118.0.
• Frappe ERPNext branch 16: affected versions are >= 16.0.0, < 16.29.0.
• The fix for branch 15 is 15.118.0; the fix for branch 16 is 16.29.0.
• The status of branches or releases not listed in the available affected data has not been established.

Frappe ERPNext processes the subject, body, and pdf_name fields in erpnext/accounts/doctype/process_statement_of_accounts/process_statement_of_accounts.py through validate_template and render_template calls. Before the fix, these calls used an unrestricted execution context that included the frappe.utils namespace. An authenticated user with a common operational role could place attacker-controlled template expressions in these fields; the server-side engine could then evaluate those expressions, execute arbitrary code on the server, and read data across the application. This is CWE-1336, caused by improper neutralization of special elements used in a template engine. The available evidence does not identify the exact role name, endpoint, or request sequence used to reach these fields.

The vulnerability is reachable over the network through the ERPNext application and requires an authenticated account. The required privilege is described as low, corresponding to a common operational role; no additional user interaction is required and the attack conditions are described as simple. The supplied record does not identify a public exploit and does not establish that the vulnerability has been exploited in the wild. No exploit code, campaign, victim, or specific indicator is identified by the available sources.

The flaw allows an authenticated user to move beyond intended template rendering and execute arbitrary code on the server. Technical consequences may include application data disclosure, data or configuration changes, and service disruption if the executed code has sufficient permissions. Because the effect can reach resources outside the template component, the scope of impact may exceed the Process Statement of Accounts function. The practical boundary depends on the privileges of the ERPNext process and the resources reachable from the server; the available evidence does not define that boundary in detail.

Successful exploitation could expose data accessible to the ERPNext server process, including data outside the user's intended business function. Arbitrary server-side code could also enable changes to application data or state, depending on the privileges of the process and connected services. The impact may extend beyond statement generation because the vulnerable templates are evaluated with an unrestricted execution context. The available evidence does not identify a breach, victim, or campaign, but that limitation does not rule out compromise of an individual deployment.

1. Upgrade ERPNext branch 15 to exactly 15.118.0, or upgrade ERPNext branch 16 to exactly 16.29.0, according to the deployed branch.
2. No vendor-confirmed workaround is available; the advisory states that upgrading is required.
3. After upgrading, verify that the fix restricts globals during template validation and rendering and that frappe.utils is no longer exposed in the Process Statement of Accounts template context.
4. Review the templates and related configuration for subject, body, and pdf_name, then investigate unauthorized changes, unexpected rendering errors, or unanticipated email and PDF generation.
5. If exploitation is suspected, investigate data access and server-side changes within the permissions available to the ERPNext process. Do not treat the absence of logs or known indicators as proof that the system was not accessed.

1. Inventory all ERPNext deployments and compare their versions with the affected branches in affected_summary.
2. Review Process Statement of Accounts records, especially subject, body, and pdf_name, for unauthorized changes or unexpected template expressions.
3. During source or package review, confirm that the relevant validate_template and render_template calls use restrict_globals=True.
4. Confirm that the template context no longer exposes the frappe.utils namespace through frappe.
5. Review logs and audit records for template edits, template validation, and email or PDF generation as a precaution. No specific IOC is confirmed, and the absence of suspicious log evidence does not prove that a system is safe.