Frappe ERPNext CVE-2025-66436

Exploitation requires an authenticated account whose role has permission to create or modify a Terms and Conditions document in ERPNext (through version 15.89.0); the attacker places a Jinja2 expression in the 'terms' field, which is later rendered by the get_terms_and_conditions method through frappe.render_template(). The key limiting factor is this write privilege - anonymous or read-only users cannot trigger it. Impact is further bounded by Frappe's custom SandboxedEnvironment, which blocks most dangerous operations; the practical attack surface is the subset of dangerous globals still exposed by get_safe_globals() (notably frappe.db.sql), constraining the outcome to database information disclosure rather than arbitrary OS-level code execution. No special non-default server configuration is stated as required.

This is a moderate, authenticated-only information-disclosure flaw rather than a top-tier priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3) is internally consistent: network-reachable, low complexity, but requiring authenticated privileges (PR:L) and yielding only limited confidentiality impact with no integrity or availability effect. Public exploit code exists (two write-ups referenced), which raises practical risk, but the CVE is NOT in CISA KEV and no EPSS score was supplied, so there is no evidence of active or widespread exploitation - POC availability and active exploitation are distinct signals and only the former is present here. There is tension between the signals and the labeling: the tags claim 'RCE' and the description says 'server-side code execution,' yet the CVSS impact is scoped to C:L/I:N/A:N (database information leakage within a restricted sandbox), so the real-world outcome is data exposure, not full unrestricted code execution - treat the 'RCE' framing with caution. No SSVC decision data was provided. Net: a real but bounded issue best prioritized for internet-exposed ERPNext tenants with untrusted or numerous low-privilege users; not an emergency patch for isolated/internal deployments.

An authenticated ERPNext user who holds permission to create or edit a Terms and Conditions document embeds a malicious Jinja2 expression (e.g. invoking frappe.db.sql) in the terms field. When get_terms_and_conditions renders that template via frappe.render_template() with the doc context, the payload executes inside Frappe's sandboxed environment and reads data the attacker should not see. Publicly available proof-of-concept write-ups demonstrate the technique.