Swetrix EUVD-2026-101249

Exploitation requires an authenticated low-privilege Swetrix account (any self-registered user suffices, PR:L) and knowledge of the victim project's public tracking ID - which is intentionally exposed in client-side tracking code and therefore not a meaningful barrier. The specific prerequisite is invoking ProjectController.addProject with the victim's projectId while supplying an attacker-created organisation, against Swetrix Cloud/self-hosted versions before 5.1.0. No user interaction from the victim is needed (UI:N) and no special non-default configuration is required. Limiting factors: the attacker must hold a valid account on the same Swetrix instance as the target, and impact is confined to individually targeted projects (one tracking ID per hijack), with no cross-system scope change.

This is a genuine, actionable access-control flaw rather than an inflated high-CVSS score. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H, 8.7) is internally consistent with the description: network-reachable, low complexity, and requiring only a low-privilege authenticated account (any registered Swetrix user), with high impact to confidentiality, integrity, and availability of the victim project. The attack is effectively automatable - an attacker only needs a victim's public tracking ID, which is by design exposed in client-side tracking code - and the technical impact is total takeover of the targeted project (read analytics, change settings, delete), supporting a 'act'-level urgency for anyone running the affected self-hosted/cloud code. Mitigating the score, this is not unauthenticated (PR:L) and scope is unchanged (SC:N/SI:N/SA:N) - compromise is confined to the hijacked project, not the whole platform. No EPSS score, no CISA KEV listing, and no public exploit were provided; exploitation status is therefore 'no public exploit identified at time of analysis,' and the absence of EPSS/KEV signals means real-world exploitation frequency cannot be gauged from the input. The root cause is confirmed by the vendor patch diff (addition of getFullProject + allowedToManage authorization checks in addProject), which independently corroborates the CWE-862 classification and the missing-authorization mechanism.

An attacker registers an ordinary Swetrix account, creates their own organisation, then calls the addProject endpoint supplying a victim project's public tracking ID (readily obtainable from the target site's tracking snippet). Because the pre-patch addProject performed no ownership/authorization check, the victim's project is moved into the attacker's organisation, granting full control to read analytics, alter settings, or delete it. No public exploit code was identified, but the trivial, scriptable nature of the request makes practical exploitation straightforward for any authenticated user.