CVE-2026-110621 is a High severity (CVSS 8.8) missing authorization flaw in Swetrix Cloud before 5.1.0. A logged in user can pull any project into their own organisation using its public tracking ID. Upgrade to Swetrix 5.1.0, the release that fixes it.
What's affected
The record says Swetrix Cloud before 5.1.0 is affected, and VulnCheck lists the same range. The project's 5.1.0 release is linked from the VulnCheck advisory as the fix. The release notes we read describe features such as two factor support and do not call out this issue by name, so treat the record and VulnCheck as the source for the fixed version.
The weakness is CWE-862, missing authorization. Per the record, the ProjectController.addProject handler does not check that the caller owns the project they are adding to an organisation. An attacker creates an organisation, then adds a victim project by its tracking ID. The record calls the tracking ID public, so it should never be treated as proof of ownership.
The record says the attacker can then read analytics, change settings or delete the project. Severity differs by source. The record gives 8.8 (High) and VulnCheck lists 8.7 on a CVSS 4.0 vector. Both are High.
How to check if you're exposed
If you use the hosted Swetrix Cloud, the provider operates the service, so the fix is theirs to deploy. Check the project's status notes and release channel for confirmation.
If you self host Swetrix, check the version you run.
docker image ls | grep -i swetrix
Anything before 5.1.0 is in range. Then check your projects. If one disappeared from your account, moved to an organisation you do not know, or had settings changed, it may have been taken. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.
What to do now
- Upgrade self-hosted Swetrix to 5.1.0 or later. The release notes warn of breaking changes and migrations, so read them and back up first.
- Review the organisation list and project membership for entries that do not belong.
- If a project went missing, contact the Swetrix project or provider and check access logs.
- Treat tracking IDs as public identifiers and never as secrets. Rely on server side checks for ownership.
- Take a backup of analytics data on a schedule so a deleted project can be restored.
Why it matters
Many web apps use identifiers that are public by design, such as a tracking ID in a script tag. That is fine as long as no server action trusts the identifier as proof of ownership. Here, knowing the ID was enough to claim a project.
The fix pattern is the same for any multi-tenant product: every action that changes ownership or membership must check that the caller owns the object. It is a simple check, and it is also one of the easiest to forget. The record does not mark this CVE as known exploited, and none of the pages we read say it is.
Quick check
Which Swetrix version fixes CVE-2026-110621?
5.1.0, per the record and VulnCheck. The release notes warn that upgrading needs migrations and configuration changes.
Is the tracking ID a secret?
The record calls it a public tracking ID. Anyone can learn it, so the server must not treat it as proof of ownership.
Sources
Last reviewed: 18 October 2026.
