Server-side template injection enables remote code execution in Frappe ERPNext

ERPNext is a free and open source Enterprise Resource Planning tool. Prior to 15.111.0 and 16.22.0, limited authenticated users can cross a permission boundary in Frappe safe execution because frappe.render_template is exposed without forcing restrict_globals, allowing server-side template injection and remote code execution. This issue is fixed in versions 15.111.0 and 16.22.0.

• Frappe ERPNext is affected at < 15.111.0.
• Frappe ERPNext is affected on the >= 16.0.0, < 16.22.0 branch range.
• The confirmed patched releases are 15.111.0 for the version 15 branch and 16.22.0 for the version 16 branch.
• Later or parallel branches not explicitly covered by these ranges should be verified separately before being treated as unaffected.

The flaw is in Frappe safe execution, where frappe.render_template was exposed to the restricted environment without forcing restrict_globals. This weakened the permission boundary between safe execution and template rendering, allowing attacker-influenced template data to be interpreted on the server. At a high level, a limited authenticated user can reach safe execution, provide template data that is interpreted as server-side expressions, cross the permission boundary, and achieve remote code execution on the server. The fix adds safe_render_template, removes caller control over restrict_globals, and always calls frappe.render_template with restrict_globals=True; the safe globals are changed to use this wrapper. The public evidence does not identify the specific endpoint or request conditions used to supply template data.

The vulnerability is reachable over the network by an authenticated user with limited privileges. The supplied attack characteristics indicate that no additional user interaction is required and that exploitation complexity is low. The impact scope is changed, so crossing the boundary in the affected component can affect resources outside the component's intended authorization scope. The supplied record marks public exploit false; the available evidence does not confirm an in-the-wild exploitation campaign, but that status does not prove exploitation is impossible.

The flaw allows a limited authenticated user to move from access to safe execution into server-side template injection and remote code execution. The resulting technical impact may affect confidentiality, integrity, and availability and may extend beyond the intended authorization scope of the original component. Organisational consequences could include unauthorized access to or modification of ERP data, server compromise, and disruption of business processes. The limiting condition is that the attacker still needs a valid account with suitable access; the public evidence does not identify every affected endpoint or deployment configuration.

• An attacker with a valid limited-privilege account may cross the safe execution permission boundary.
• Remote code execution on the server can potentially lead to full compromise of the ERPNext system, as described by the advisory.
• Possible consequences include unauthorized access to ERP data, modification of business records, or service disruption, but the record does not describe a specific breach, victim, or campaign.
• Because an authenticated account is required, exposure assessment should focus on all limited accounts that can reach safe execution functionality.

1. Upgrade ERPNext to 15.111.0 for the version 15 branch or 16.22.0 for the version 16 branch, according to the deployed branch.
2. Inventory all sites, workers, and servers running ERPNext so that no instance remains within the affected ranges.
3. After upgrading, verify that safe execution uses the restricted wrapper with restrict_globals=True instead of directly exposing frappe.render_template without forced global restrictions.
4. The developer advisory states that no workaround is available. Until the confirmed fix is deployed, do not treat an unverified configuration change as equivalent to the patch.
5. Review limited-privilege accounts that can access safe execution and investigate unusual related activity from the period before remediation.

• Inventory every ERPNext deployment and its associated Frappe version, then compare the results with the affected ranges in affected_summary.
• Confirm that the deployed code uses the fix in which safe globals call the restricted wrapper instead of exposing frappe.render_template directly.
• Review authentication and application logs for unusual safe execution or template-rendering activity initiated by limited-privilege accounts. Treat this as precautionary monitoring, not as a confirmed indicator of compromise.
• Do not treat the absence of suspicious log events as proof of safety; verify exposure through inventory and patched-version checks.