CVE-2026-110621 in Cloud
Summary
by MITRE • 10/14/2026
Swetrix Cloud before 5.1.0 contains a missing authorization vulnerability in ProjectController.addProject that allows authenticated users to hijack arbitrary projects by moving them into their own organisation. Attackers can create an organisation and add a victim project by its public tracking ID to read analytics, change settings, or delete it.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The identified security flaw resides within the Swetrix Cloud platform prior to version 5.1.0, specifically affecting the ProjectController.addProject endpoint. This vulnerability is classified as a missing authorization issue, which falls under CWE-284: Improper Access Control in standard cybersecurity taxonomies. The core technical defect lies in the application's failure to validate whether an authenticated user possesses legitimate ownership or administrative privileges over a target project before allowing it to be associated with their organization. Instead of verifying existing permissions against the resource being modified, the system relies solely on the presence of valid authentication credentials and the provision of the public tracking ID for the target project. This design oversight creates a critical gap where any authenticated user can manipulate resources they do not own by exploiting the trust placed in publicly available identifiers.
From an operational perspective, this vulnerability enables attackers to perform unauthorized account takeover-like actions against specific projects rather than entire accounts. By creating their own organization within the platform and subsequently invoking the addProject method with a victim's public tracking ID, an attacker can effectively hijack that project. Once the project is moved into the attacker-controlled organization, they gain full administrative control over it. This capability allows for significant malicious activities including reading sensitive analytics data which may contain personally identifiable information or business-critical metrics, altering configuration settings to disrupt service operations, or permanently deleting the project and its associated historical data. The impact extends beyond simple data theft as it compromises the integrity and availability of services provided by Swetrix Cloud customers who rely on accurate tracking and analysis capabilities.
In terms of threat modeling, this attack vector aligns with ATT&CK technique T1078: Valid Accounts, specifically focusing on account manipulation rather than initial access since authentication is required but privileges are escalated through misconfiguration. The exploitation requires no special tools or complex payloads; it can be executed using standard HTTP requests to the API endpoint once an attacker has registered for a Swetrix Cloud account and identified target tracking IDs which are often embedded in web pages, mobile applications, or shared publicly on forums and documentation sites. This ease of discovery combined with low barrier to entry makes this vulnerability particularly dangerous for organizations that may inadvertently expose their project identifiers through public-facing assets without realizing the administrative implications if those identifiers were compromised.
To mitigate this risk, immediate action is required by upgrading Swetrix Cloud installations to version 5.1.0 or later where these authorization checks have been implemented correctly. For environments unable to upgrade immediately, administrators should review API usage logs for unusual patterns of project additions and restrict public exposure of tracking IDs wherever possible through obfuscation techniques such as using dynamic token generation rather than static identifiers in client-side code. Additionally implementing strict input validation on the server side that cross-references the requesting user's identity with existing ownership records before processing any modification requests is essential to prevent similar flaws in other endpoints. Regular security audits focusing on access control logic across all API controllers will help ensure that future development adheres to principle of least privilege and prevents unauthorized resource manipulation.