Mautic CVE-2026-115193

Requires (1) at least one custom contact field configured with the HTML field type in Mautic 7.0.0 through 7.2.1, (2) an attacker-controlled write path to that field - contact editing, the contact API, or a public/updatable form field mapped to the HTML custom field, and (3) a second, more-privileged user or administrator subsequently opening the affected contact's detail view, which is the UI:R trigger. Limiting factors: versions 4.x, 5.x, and 6.x are not affected because they escape such values; the unauthenticated path only exists where a public form is intentionally mapped to an HTML field, otherwise write access needs an account or API token; and nothing fires until a victim views the contact. The vendor states there is no official workaround - mitigation short of upgrading is limited to restricting contact create/edit and API access to trusted users and not mapping public form fields to HTML-type contact fields; upgrading to 7.2.2 is the only complete fix.

This is a credible, elevated-priority issue rather than a CVSS-inflated non-event, but the raw 8.2 overstates the ease of drive-by exploitation. The supplied CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N) scores PR:N, yet the description qualifies exploitation as achievable by 'a user or integration able to write a value' to an HTML-type custom contact field - i.e. typically an authenticated user or API client, with the unauthenticated path existing only when a public form is deliberately mapped to such a field. That is a conflict worth flagging: the PR:N rating appears to assume the non-default public-form mapping, so for most deployments realistic exploitation requires some write privilege. The vulnerability class (stored XSS, S:C) is genuine - injected script runs in the session of whoever views the contact, up to an administrator, enabling account creation and config changes. EPSS is not provided, there is no CISA KEV listing, and no SSVC decision block was supplied; the only prioritization signal is the vuln.today 'this_week' label. No public exploit code is referenced (the single reference is the vendor GHSA advisory, not a PoC). Net: real and patchable now, but it depends on an attacker-controlled write path plus a privileged victim opening the contact, making it targeted rather than mass/wormable.

An attacker who can write to an HTML-type custom contact field - via the contact edit UI, the contact API, or a public form mapped to that field - stores a JavaScript payload in it. When a Mautic operator or administrator later opens that contact's detail page, the script executes in their authenticated session and performs actions on their behalf, such as creating a new administrator account or reading contact and campaign data. No public exploit code is identified at time of analysis; the UI:R requirement means a privileged user must view the poisoned contact for the payload to fire.