Summary
Mautic 7 contains a stored Cross-Site Scripting vulnerability in the contact detail view because HTML-type custom contact field values are rendered without sufficient output sanitization. An attacker who can write a value to an affected field may cause script to execute when another user, including an administrator, views the contact.
Mautic 7 contains a stored Cross-Site Scripting vulnerability in the contact detail view because HTML-type custom contact field values are rendered without sufficient output sanitization. An attacker who can write a value to an affected field may cause script to execute when another user, including an administrator, views the contact.
Affected context
The issue occurs in Mautic contact detail pages when HTML-type custom contact fields contain attacker-controlled content and that content is rendered in a user's browser without appropriate context-aware sanitization. The value may enter through contact editing, an API integration, or a form submission mapped to the custom field. Risk depends on whether an attacker can write to the field and whether another privileged user views the affected contact.
The issue occurs in Mautic contact detail pages when HTML-type custom contact fields contain attacker-controlled content and that content is rendered in a user's browser without appropriate context-aware sanitization. The value may enter through contact editing, an API integration, or a form submission mapped to the custom field. Risk depends on whether an attacker can write to the field and whether another privileged user views the affected contact.
Exploit preconditions
- Attack surface: Contact detail view in the Mautic web interface
- Required access: Permission or integration capability to write a value to an HTML-type custom contact field
- Trigger point: A user opens the affected contact's detail page
- Why exploitation is possible: Stored field content is rendered without adequate output sanitization, allowing browser-executable markup or script to reach the victim's session context
- Attack surface: Contact detail view in the Mautic web interface
- Required access: Permission or integration capability to write a value to an HTML-type custom contact field
- Trigger point: A user opens the affected contact's detail page
- Why exploitation is possible: Stored field content is rendered without adequate output sanitization, allowing browser-executable markup or script to reach the victim's session context
Why this happens
The vulnerability results from treating user-controlled HTML field values as trusted display content. When output is rendered without context-appropriate sanitization or a tightly restricted allowlist, an attacker can store content that the browser interprets as active script.
This maps to CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), specifically a stored XSS pattern in which malicious input persists in application data and executes when later displayed.
The vulnerability results from treating user-controlled HTML field values as trusted display content. When output is rendered without context-appropriate sanitization or a tightly restricted allowlist, an attacker can store content that the browser interprets as active script.
This maps to CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), specifically a stored XSS pattern in which malicious input persists in application data and executes when later displayed.
Potential impact
- An attacker may perform actions available to the victim's active session
- Administrative users could have accounts or system settings modified
- Contact and campaign data could be accessed or altered
- The application session or browser context could be abused
- Malicious content could execute for multiple users who view the affected contact
- An attacker may perform actions available to the victim's active session
- Administrative users could have accounts or system settings modified
- Contact and campaign data could be accessed or altered
- The application session or browser context could be abused
- Malicious content could execute for multiple users who view the affected contact
General mitigation guidance
Mitigation generally focuses on reducing trust in custom field values and applying output controls at the point where content is rendered.
Common defensive patterns include:
- Applying context-aware output encoding or sanitization before rendering field values
- Using a strict HTML allowlist when limited formatting is required
- Treating API, form, and user-entered field values as untrusted regardless of their declared field type
- Enforcing consistent sanitization across contact views, exports, previews, and administrative interfaces
- Restricting permissions for writing HTML-type custom fields
- Applying effective Content Security Policy controls as a defense-in-depth measure
- Limiting administrative privileges and separating contact-editing permissions from system administration
Mitigation generally focuses on reducing trust in custom field values and applying output controls at the point where content is rendered.
Common defensive patterns include:
- Applying context-aware output encoding or sanitization before rendering field values
- Using a strict HTML allowlist when limited formatting is required
- Treating API, form, and user-entered field values as untrusted regardless of their declared field type
- Enforcing consistent sanitization across contact views, exports, previews, and administrative interfaces
- Restricting permissions for writing HTML-type custom fields
- Applying effective Content Security Policy controls as a defense-in-depth measure
- Limiting administrative privileges and separating contact-editing permissions from system administration
How teams detect issues like this
Detection can include static analysis for direct insertion of custom field values into HTML, templates, or client-side DOM sinks without contextual encoding or sanitization. Code review should examine every rendering path for HTML-type fields, including contact detail pages, previews, API-backed interfaces, and administrative views.
Dynamic testing can store harmless marker content in affected fields and verify that it is rendered as text or approved markup rather than executable content. Policy enforcement may require approved sanitization helpers, template auto-escaping, restricted HTML allowlists, and automated security checks in pull requests. Automated review tools can help identify common unsafe output and DOM manipulation patterns.
Detection can include static analysis for direct insertion of custom field values into HTML, templates, or client-side DOM sinks without contextual encoding or sanitization. Code review should examine every rendering path for HTML-type fields, including contact detail pages, previews, API-backed interfaces, and administrative views.
Dynamic testing can store harmless marker content in affected fields and verify that it is rendered as text or approved markup rather than executable content. Policy enforcement may require approved sanitization helpers, template auto-escaping, restricted HTML allowlists, and automated security checks in pull requests. Automated review tools can help identify common unsafe output and DOM manipulation patterns.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
