Summary
Frappe ERPNext contains a stored cross-site scripting vulnerability in content submitted through a public-facing booking page. An unauthenticated attacker may store crafted content that executes JavaScript when rendered in a privileged user's session, potentially enabling actions as that user and account takeover.
Frappe ERPNext contains a stored cross-site scripting vulnerability in content submitted through a public-facing booking page. An unauthenticated attacker may store crafted content that executes JavaScript when rendered in a privileged user's session, potentially enabling actions as that user and account takeover.
Affected context
The issue can occur in ERPNext deployments where a public booking page accepts user-controlled content and stores it without adequate neutralization or output encoding. Risk increases when that content is later displayed as raw HTML in sessions belonging to administrators or other privileged users.
The issue can occur in ERPNext deployments where a public booking page accepts user-controlled content and stores it without adequate neutralization or output encoding. Risk increases when that content is later displayed as raw HTML in sessions belonging to administrators or other privileged users.
Exploit preconditions
- Attack surface: Public-facing booking page or related content submission endpoint
- Required access: No authentication may be required to submit the crafted content
- Trigger point: A privileged user views the stored booking content
- Why exploitation is possible: Submitted content is persisted without sufficient neutralization and later rendered as executable HTML or script in the viewer's browser
- Attack surface: Public-facing booking page or related content submission endpoint
- Required access: No authentication may be required to submit the crafted content
- Trigger point: A privileged user views the stored booking content
- Why exploitation is possible: Submitted content is persisted without sufficient neutralization and later rendered as executable HTML or script in the viewer's browser
Why this happens
The vulnerability results from accepting attacker-controlled content, storing it, and rendering it without context-appropriate output encoding or sanitization. This is a stored cross-site scripting condition mapped to CWE-79: Improper Neutralization of Input During Web Page Generation, where untrusted data is interpreted as active browser content in a user's security context.
The vulnerability results from accepting attacker-controlled content, storing it, and rendering it without context-appropriate output encoding or sanitization. This is a stored cross-site scripting condition mapped to CWE-79: Improper Neutralization of Input During Web Page Generation, where untrusted data is interpreted as active browser content in a user's security context.
Potential impact
- An attacker may execute script in a privileged user's browser session
- The attacker could perform actions available to the affected user
- Session-related information or sensitive page data may be exposed
- Administrative users could be induced to modify configuration or user access
- The vulnerability can contribute to account takeover
- An attacker may execute script in a privileged user's browser session
- The attacker could perform actions available to the affected user
- Session-related information or sensitive page data may be exposed
- Administrative users could be induced to modify configuration or user access
- The vulnerability can contribute to account takeover
General mitigation guidance
Mitigation generally focuses on reducing trust in public submissions and ensuring that all user-controlled content is safely handled at output boundaries.
Common defensive patterns include:
- Applying context-aware output encoding before rendering submitted content
- Sanitizing permitted rich text with a restrictive, well-maintained allowlist
- Avoiding raw HTML rendering for untrusted booking data
- Validating content on the server side and treating client-side checks as insufficient
- Separating public submission data from privileged administrative interfaces where practical
- Applying least privilege to user roles and limiting sensitive actions available to sessions that view submitted content
- Using browser security controls such as an appropriately restrictive Content Security Policy
Mitigation generally focuses on reducing trust in public submissions and ensuring that all user-controlled content is safely handled at output boundaries.
Common defensive patterns include:
- Applying context-aware output encoding before rendering submitted content
- Sanitizing permitted rich text with a restrictive, well-maintained allowlist
- Avoiding raw HTML rendering for untrusted booking data
- Validating content on the server side and treating client-side checks as insufficient
- Separating public submission data from privileged administrative interfaces where practical
- Applying least privilege to user roles and limiting sensitive actions available to sessions that view submitted content
- Using browser security controls such as an appropriately restrictive Content Security Policy
How teams detect issues like this
Organizations can look for stored XSS risks through:
- Static analysis rules identifying unsafe HTML rendering and direct insertion of user-controlled values
- Code review checks for missing output encoding, weak sanitization, or unsafe rich-text allowlists
- Tests that submit representative markup and verify it is rendered inert in every viewing context
- Monitoring public booking records for unexpected markup, event-handler attributes, or script-like content
- Policy enforcement requiring server-side validation and context-specific encoding for all untrusted content
- Automated security review tools that flag data flows from public inputs to HTML sinks
Organizations can look for stored XSS risks through:
- Static analysis rules identifying unsafe HTML rendering and direct insertion of user-controlled values
- Code review checks for missing output encoding, weak sanitization, or unsafe rich-text allowlists
- Tests that submit representative markup and verify it is rendered inert in every viewing context
- Monitoring public booking records for unexpected markup, event-handler attributes, or script-like content
- Policy enforcement requiring server-side validation and context-specific encoding for all untrusted content
- Automated security review tools that flag data flows from public inputs to HTML sinks
