CVE-2025-8795 is a medium severity improper access control flaw in LitmusChaos Litmus up to version 3.19.0. The projectID argument at /auth/login leads to access the caller should not have. The record says the vendor did not respond to the reporter, so check the project's releases for a fix.
What's affected
- Product: LitmusChaos Litmus, versions up to and including 3.19.0.
- Component: the
/auth/loginroute, through theprojectIDargument. - Weaknesses: CWE-266 (incorrect privilege assignment) and CWE-284 (improper access control).
- Score: CVSS 3.1 base 6.3, Medium, vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L. It is network reachable and needs a low privileged account. - Fixed version: not confirmed. The record says the vendor was contacted early and did not respond, and I could not retrieve a vendor advisory.
The record's description calls the issue "critical" while its score of 6.3 is Medium. This post follows the score. The record says the exploit has been disclosed publicly. It is not flagged as exploited in the wild and is not in the CISA Known Exploited Vulnerabilities catalog.
How to check if you're exposed
Litmus is a chaos engineering platform that usually runs inside a Kubernetes cluster. Find the version of your installation and see whether it is 3.19.0 or earlier.
helm list -A | grep -i litmus
kubectl get deploy -A -o wide | grep -i litmus
The image tags in the second command show what is running. If your platform team installed it from a manifest, read the version from there.
Then consider who has accounts. The flaw needs a low privileged login, so a Litmus instance used by a small trusted team is less exposed than one open to many projects or tenants. The weakness concerns the project identifier in the login path, which suggests that the boundary between projects is what is at stake. Review which users belong to which projects and whether anyone has access they should not.
What to do now
- Inventory every Litmus installation and its version.
- Read the project's release notes for a version newer than 3.19.0 and upgrade when one covers this report. If you cannot confirm that, say so in your ticket and keep the next steps in place.
- Restrict network access to the Litmus control plane to the teams that use it.
- Review project membership and remove accounts that do not need access.
- Remember what Litmus can do. It runs experiments that disrupt workloads, so limit who can trigger them in production clusters.
- Check audit logs for logins or project switches that you cannot explain.
Why it matters
A chaos tool is built to break things on purpose, and the people allowed to drive it have real power over a cluster. Access control on such a tool is part of your production safety, not an internal convenience.
The weaknesses here are privilege and access control errors, which means the system does not hold the line between what one user may touch and what another may. Those are the issues that matter in multi tenant setups. With no vendor response, plan to rely on network limits and account hygiene while you watch for a release.
You can run the free in-browser dependency scan at gold.safeguard.sh/scan on your manifests to see which known-vulnerable packages you carry. It reads dependencies, so it will not see a flaw that lives only in an application's own source.
Quick check
Is Litmus 3.19.0 safe?
No. The record lists versions up to and including 3.19.0 as affected.
Is there an official fix?
It is not confirmed here. The record says the vendor did not respond, and I could not retrieve an advisory. Check the project releases.
Sources
- Safeguard Gold entry: CVE-2025-8795 (NVD record data: description, CVSS, CWEs, published 2025-08-10)
- Researcher write-up listed in the record: readme05.md
Last reviewed: 18 October 2026.
