CVE-2026-115195 in Mautic
Summary
by MITRE • 10/26/2026
A broken access control vulnerability exists in the Mautic Stats API (/api/stats/{table}). The endpoint did not enforce permissions for several internal tables: an intended administrator-only restriction was never applied, and tables without an explicit permission mapping were readable by default. As a result, any authenticated API user, including one whose role grants no permissions, could read data from these tables, including the application audit log with actions performed by all users and change details that may contain contact personal data, stored visitor IP addresses and their geolocation details, and tracked redirect URLs and their channel mappings.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in Mautic represents a critical failure in access control mechanisms within the Stats API endpoint located at /api/stats/{table}. This flaw stems from an incomplete implementation of authorization checks, specifically where the application fails to enforce role-based restrictions on certain internal database tables. While some endpoints correctly restrict access based on user roles, this particular path lacks these safeguards for a subset of resources. The root cause is twofold: first, there is a missing permission check for tables that are explicitly intended to be administrator-only, and second, the system defaults to allowing read access for any table that does not have an explicit negative permission mapping defined in its configuration. This design oversight creates a significant security gap where authentication alone is sufficient to bypass authorization requirements, violating the principle of least privilege which dictates that users should only have access to the resources strictly necessary for their function.
From a technical perspective, this vulnerability allows any authenticated API user, regardless of their assigned role or permission level, to query and retrieve data from sensitive internal tables. The attacker does not need elevated privileges such as administrator rights; even a guest account with no specific permissions can exploit this flaw. By manipulating the {table} parameter in the URL path, an adversary can request information stored in these unprotected endpoints. This bypasses the intended security model where administrative logs and personally identifiable information are restricted to high-privilege accounts only. The lack of explicit deny rules for certain tables means that if a table is not explicitly marked as private or protected by code logic, it becomes publicly accessible within the context of authenticated API calls.
The operational impact of this vulnerability is severe due to the sensitivity of the data exposed through these endpoints. Attackers can access the application audit log, which contains detailed records of actions performed by all users in the system. This includes timestamps, user identifiers, and specific operations executed, providing a comprehensive history that could be used for further reconnaissance or social engineering attacks. Additionally, the vulnerability exposes contact personal data stored within the CRM database, potentially including names, email addresses, and other demographic information. Furthermore, visitor IP addresses along with their derived geolocation details are accessible, which poses significant privacy risks under regulations such as GDPR. Tracked redirect URLs and their associated channel mappings are also exposed, revealing marketing campaign structures and traffic sources that could be used to disrupt business operations or gain insights into organizational strategies.
This vulnerability aligns closely with CWE-284, Improper Access Control, specifically the sub-category of insufficient authorization checks in API endpoints. It also maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as it allows an attacker to leverage legitimate credentials to access unauthorized resources. The ability to read audit logs and personal data constitutes a significant breach of confidentiality and integrity standards. Organizations relying on Mautic for marketing automation must recognize that this exposure compromises not only the privacy of their contacts but also the internal operational security by revealing administrative activities and system configurations.
To mitigate this risk, immediate remediation is required at both the code level and configuration management layers. Developers should enforce explicit permission checks for all API endpoints, ensuring that every request to /api/stats/{table} validates the user's role against a strict allow-list of permitted tables rather than relying on implicit defaults. The application logic must be updated to deny access by default unless explicitly granted, adhering to secure coding best practices. Administrators should apply any available security patches provided by Mautic vendors promptly. In the interim, network-level controls such as Web Application Firewalls can be configured to restrict API traffic based on user roles if possible, though this is a compensating control rather than a fix. Regular security audits and penetration testing focusing on broken access control scenarios are recommended to identify similar flaws in other parts of the application before they can be exploited by malicious actors seeking sensitive organizational data.