Frappe ERPNext CVE-2026-109633

Exploitation requires that the ERPNext instance exposes a PUBLIC booking page that accepts externally-submitted content and renders it as raw HTML (the specific vulnerable feature). The attacker needs no authentication to plant the payload (PR:N), but exploitation only completes when a privileged/authenticated user subsequently opens and views the attacker-controlled booking content (UI:P) - this user-interaction requirement is the primary limiting factor and means the attack is not fully automatable to immediate impact. Instances not exposing the public booking feature to untrusted submitters, or running fixed versions (>=15.119.1, or 16.x >=16.32.0), are not exploitable.

This is a genuine priority within environments running the affected product, not merely a high-score-on-paper issue. The CVSS 4.0 base score of 8.6 (HIGH) is driven by a network attack vector (AV:N), low complexity (AC:L), and crucially no privileges required (PR:N) - the malicious content is submitted through a PUBLIC-facing booking page, so any anonymous internet attacker can plant the payload. The high VC:H/VI:H values reflect full account takeover of a privileged user. The main mitigating signal is UI:P (passive user interaction required): exploitation only completes when a privileged/back-office user views the attacker-submitted booking content, so there is a human-in-the-loop delay and the attacker cannot control exact timing. No EPSS score was provided in the input, so real-world exploitation probability cannot be quantified. The vulnerability is NOT listed in CISA KEV and no public exploit code was referenced - exploitation status is 'no public exploit identified at time of analysis.' Signals are internally consistent (network vector matches a public web form; stored XSS matches CWE-79), with no contradictions between the CVSS vector and the description. Net: treat as high-priority patching for any internet-exposed ERPNext instance using public booking pages, while recognizing that successful account takeover depends on a privileged user opening the poisoned record.

An unauthenticated attacker submits a booking request through ERPNext's public-facing booking page, embedding a crafted HTML/JavaScript payload in a field that is later rendered as raw HTML. When a back-office staff member or administrator opens that booking in their authenticated session, the stored script executes in their browser, letting the attacker steal session context and act as the privileged user to take over the account. No public proof-of-concept exploit was identified in the provided sources.