Summary
Cal.com up to version 4.7.15 contains a stored cross-site scripting flaw where booking-question labels are rendered with React's dangerouslySetInnerHTML without sanitization.
An attacker who can define event types with malicious labels can persist arbitrary HTML/JavaScript that executes in a victim's browser when the crafted booking page is opened.
Cal.com up to version 4.7.15 contains a stored cross-site scripting flaw where booking-question labels are rendered with React's dangerouslySetInnerHTML without sanitization.
An attacker who can define event types with malicious labels can persist arbitrary HTML/JavaScript that executes in a victim's browser when the crafted booking page is opened.
Affected context
This vulnerability occurs in the single booking view of Cal.com where booking-question field labels are rendered directly into the DOM.
It is relevant when user-controlled label text is treated as HTML rather than plain text and no server-side or client-side sanitization removes active script content.
Deployments that allow users or integrations to create or modify event types with custom booking questions are particularly exposed, as these labels may be displayed to other users without additional trust checks.
This vulnerability occurs in the single booking view of Cal.com where booking-question field labels are rendered directly into the DOM.
It is relevant when user-controlled label text is treated as HTML rather than plain text and no server-side or client-side sanitization removes active script content.
Deployments that allow users or integrations to create or modify event types with custom booking questions are particularly exposed, as these labels may be displayed to other users without additional trust checks.
Exploit preconditions
- Attack surface: Web-based booking pages (e.g.,
/booking/<id>). - Required access: Ability to create or edit an event type and define booking-question labels (often via a legitimate user account or compromised account).
- Trigger point: A victim visits the crafted booking URL where the malicious label is rendered.
- Why exploitation is possible: The application uses React's
dangerouslySetInnerHTMLto insert label content into the page without sanitizing or escaping user-supplied HTML, allowing script execution in the victim's browser.
- Attack surface: Web-based booking pages (e.g.,
/booking/<id>). - Required access: Ability to create or edit an event type and define booking-question labels (often via a legitimate user account or compromised account).
- Trigger point: A victim visits the crafted booking URL where the malicious label is rendered.
- Why exploitation is possible: The application uses React's
dangerouslySetInnerHTMLto insert label content into the page without sanitizing or escaping user-supplied HTML, allowing script execution in the victim's browser.
Why this happens
The underlying bug arises from treating user-provided text as trusted HTML and injecting it into the DOM using React's dangerouslySetInnerHTML.
Because no robust sanitization or encoding is applied to booking-question labels, attacker-controlled markup is interpreted as executable script by the browser.
This maps to CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS), where untrusted data is included in web pages without neutralizing active content.
The underlying bug arises from treating user-provided text as trusted HTML and injecting it into the DOM using React's dangerouslySetInnerHTML.
Because no robust sanitization or encoding is applied to booking-question labels, attacker-controlled markup is interpreted as executable script by the browser.
This maps to CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS), where untrusted data is included in web pages without neutralizing active content.
Potential impact
- Attackers can execute arbitrary JavaScript in the context of the victim's session.
- Session cookies or authentication tokens may be accessed, potentially leading to account hijacking depending on cookie flags and APIs exposed.
- Sensitive booking-related information displayed or accessible through the UI can be exfiltrated via injected script.
- The UI may be modified to perform phishing attacks, misleading prompts, or unauthorized actions on behalf of the victim.
- Malicious scripts can perform CSRF-like actions using the victim's credentials against the Cal.com application or integrated services.
- Attackers can execute arbitrary JavaScript in the context of the victim's session.
- Session cookies or authentication tokens may be accessed, potentially leading to account hijacking depending on cookie flags and APIs exposed.
- Sensitive booking-related information displayed or accessible through the UI can be exfiltrated via injected script.
- The UI may be modified to perform phishing attacks, misleading prompts, or unauthorized actions on behalf of the victim.
- Malicious scripts can perform CSRF-like actions using the victim's credentials against the Cal.com application or integrated services.
General mitigation guidance
Effective mitigation focuses on preventing untrusted content from becoming executable in the browser:
- Treat booking-question labels and similar fields as plain text, applying strict HTML escaping by default.
- Avoid
dangerouslySetInnerHTMLfor user-controlled content; where HTML rendering is required, use vetted, allowlist-based sanitization libraries that strip scripts, event handlers, and dangerous attributes. - Enforce server-side validation to restrict labels to benign characters and markup, reducing the chance of script injection.
- Apply content security policies (CSP) that limit inline scripts and disallow unsafe dynamic execution to reduce impact if some injection occurs.
- Design privilege models so that high-risk HTML-rendering paths only consume data from trusted sources, and keep untrusted user input separate from rich-content features.
Effective mitigation focuses on preventing untrusted content from becoming executable in the browser:
- Treat booking-question labels and similar fields as plain text, applying strict HTML escaping by default.
- Avoid
dangerouslySetInnerHTMLfor user-controlled content; where HTML rendering is required, use vetted, allowlist-based sanitization libraries that strip scripts, event handlers, and dangerous attributes. - Enforce server-side validation to restrict labels to benign characters and markup, reducing the chance of script injection.
- Apply content security policies (CSP) that limit inline scripts and disallow unsafe dynamic execution to reduce impact if some injection occurs.
- Design privilege models so that high-risk HTML-rendering paths only consume data from trusted sources, and keep untrusted user input separate from rich-content features.
How teams detect issues like this
Detection typically centers around identifying unsafe rendering paths and patterns:
- Static analysis or linting rules can flag uses of
dangerouslySetInnerHTML, directinnerHTMLassignments, or similar APIs where the data source is user-controlled. - Code review checklists can require explicit justification and sanitization for any HTML injection mechanisms, focusing on components that render customizable labels or descriptions.
- Security testing and automated scanners can fuzz booking pages and other dynamic views with common XSS payloads to surface reflected or stored script execution.
- Logging and monitoring of unusual script behavior, browser-side errors, or anomalous booking activity can help detect exploitation attempts.
- Policy-based enforcement in CI (e.g., preventing merges that introduce new unsanitized HTML sinks) can reduce the chance of reintroducing similar flaws.
Detection typically centers around identifying unsafe rendering paths and patterns:
- Static analysis or linting rules can flag uses of
dangerouslySetInnerHTML, directinnerHTMLassignments, or similar APIs where the data source is user-controlled. - Code review checklists can require explicit justification and sanitization for any HTML injection mechanisms, focusing on components that render customizable labels or descriptions.
- Security testing and automated scanners can fuzz booking pages and other dynamic views with common XSS payloads to surface reflected or stored script execution.
- Logging and monitoring of unusual script behavior, browser-side errors, or anomalous booking activity can help detect exploitation attempts.
- Policy-based enforcement in CI (e.g., preventing merges that introduce new unsanitized HTML sinks) can reduce the chance of reintroducing similar flaws.
