Mautic EUVD-2026-109796

Two concrete preconditions must both hold: (1) the Mautic API must be enabled on the instance, and (2) the attacker must possess a valid Mautic account with API access (CVSS PR:L - authenticated). Given those, exploitation targets the dashboard widget data endpoint /api/data/{type} by supplying malicious chart filter parameters that are not validated before being used in the reporting database queries. Limiting factors that reduce real-world exposure: deployments with the API disabled (or restricted to trusted users, the vendor's stated mitigation) are not exploitable, and no unauthenticated path exists. Affected: mautic/core >= 2.8.1 and < 5.2.12, >= 6.0.0 and < 6.0.10, and >= 7.0.0 and < 7.2.2; the vulnerable version range is broad.

This is a genuine but conditional priority rather than an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L, base 7.1) describes a network-reachable, low-complexity attack that nonetheless requires authentication (PR:L) - specifically a valid Mautic user with API access. No EPSS score, no CISA KEV listing, and no SSVC machine-readable decision block were supplied; the only priority signal is the vuln.today 'this_week' label, which aligns with a confirmed high-confidentiality impact (password-hash disclosure) gated behind authentication. The sole reference is the vendor's own GHSA advisory, not an exploit, so this is not confirmed as actively exploited and no public exploit code is identified. The confidentiality impact is high (arbitrary read of the Mautic database including user credential hashes via blind SQLi), while integrity is explicitly unaffected (no data modification) and availability impact is limited to query slowdown - the CVSS I:N/A:L mapping is consistent with the description. The main thing tempering real-world risk is the dual precondition that the Mautic API must be enabled AND the attacker must already hold an API-capable account; absent those, the endpoint is not reachable. No signals conflict with one another; the chief gap is the absence of EPSS/KEV/POC telemetry, so exploitation likelihood cannot be quantified from the input.

An authenticated Mautic user with API access sends crafted chart filter parameters to the /api/data/{type} dashboard widget endpoint on an instance where the API is enabled. Because the filters are concatenated into reporting SQL without validation, the attacker uses blind (boolean/time-based) SQL injection to exfiltrate arbitrary database contents - marketing/contact data and user password hashes - one inference at a time. No public exploit code is identified at time of analysis; only the vendor GHSA advisory is referenced.