What is the CVSS score of EUVD-2026-33278?

EUVD-2026-33278 has a CVSS 3.1 base score of 7.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N. EPSS exploitation probability: 0.0%.

Which versions of Mautic are affected by EUVD-2026-33278?

Mautic 7's API v2 contains an authorization bypass allowing authenticated low-privilege users to access and modify marketing data owned by other users, directly undermining data governance and access…. A patch is available.

How to fix or mitigate EUVD-2026-33278?

24 hours: Conduct inventory of all Mautic 7 API v2 consumers and identify low-privilege accounts with active API access. 7 days: Restrict API v2 endpoint access via network segmentation to authorized systems only; disable API credentials for non-essential low-privilege accounts; enable API request logging with real-time alerting. 30 days: Monitor Mautic advisory GHSA-2jrw-c95w-h43g for patch release; evaluate upgrade timeline to patched Mautic version when available; implement Web Application Firewall rules to block suspicious cross-user API requests.

Mautic EUVD-2026-33278

| CVE-2026-9808 HIGH

Incorrect Authorization (CWE-863)

2026-05-29 Mautic

GHSA-2jrw-c95w-h43g

Authentication Bypass

7.1

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.1 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

Low

Availability

None

Lifecycle Timeline

Analysis Generated

May 29, 2026 - 12:20 vuln.today

DescriptionCVE.org

An authorization bypass vulnerability exists in the Mautic 7 API v2 endpoints (utilizing API Platform). Under certain conditions, roles configured with owner-scope restrictions (such as viewown or editown) are not properly enforced. This allows low-privilege authenticated API users to bypass ownership-logic controls and access or modify resources belonging to other users.

AnalysisAI

Authorization bypass in Mautic 7 API v2 endpoints allows authenticated low-privilege users to read or modify records owned by other users, undermining role-based ownership scopes such as viewown and editown. The flaw was reported by Mautic and disclosed via GHSA-2jrw-c95w-h43g; no public exploit identified at time of analysis and the issue is not listed in CISA KEV.

Technical ContextAI

Mautic is an open-source marketing automation platform whose v2 REST API is built on top of API Platform, a Symfony-based framework that auto-generates CRUD endpoints from PHP entity classes. The root cause maps to CWE-863 (Incorrect Authorization): API Platform request handlers do not consistently invoke Mautic's ownership-scope checks that the role/permission layer (viewown, editown) is supposed to enforce. As a result, ownership filtering implemented at the controller/voter layer for the legacy UI is bypassed when records are accessed through the API Platform-generated routes, so the permission name suggests a per-owner restriction that the framework never actually applies.

Affected ProductsAI

Mautic 7.x deployments exposing the API v2 endpoints implemented via API Platform are affected; exact fixed version is not stated in the provided intelligence and no CPE strings were supplied. The authoritative reference is the vendor security advisory at https://github.com/mautic/mautic/security/advisories/GHSA-2jrw-c95w-h43g, which should be consulted for the precise affected version range and patched release.

RemediationAI

Patch availability is indicated by the GHSA advisory but no exact fix version was included in the input - administrators should consult https://github.com/mautic/mautic/security/advisories/GHSA-2jrw-c95w-h43g for the patched Mautic 7 release and upgrade to it as the primary remediation. As compensating controls until patching, audit and tighten role assignments so that no production API user holds owner-scope roles (viewown/editown) under the assumption they restrict cross-user access, revoke or rotate API credentials for low-trust accounts, and restrict network reachability of the /api/* endpoints to trusted IP ranges via a reverse proxy or WAF; note the trade-off that locking down /api breaks legitimate integrations (Zapier, custom CRM sync) and that elevating users above owner-scope is not a fix - it removes the broken control entirely rather than enforcing it.