Leantime CVE-2026-94211

Exploitation requires an authenticated Leantime account with EDIT permission on the target project to plant the payload into a project status/label name, and a second user (typically the Owner) must subsequently view the Project Dashboard (/app/Domain/Dashboard/Templates/show.blade.php) for the raw-echoed label to fire - this cross-user viewing is the UI:P requirement. Limiting factors: it is not exploitable against a single-user instance, needs insider write access rather than anonymous reach, and impact is confined to script execution in a victim's browser session (no direct server compromise). Applies to Leantime up to and including 3.9.8.

This is a genuine but modest-severity stored XSS. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:P/VC:N/VI:L/VA:N, base 4.8) confirms network reach but with meaningful gating: an attacker must already hold write/edit access to a project and a victim must view the poisoned dashboard (UI:P). Confidentiality impact is rated none and integrity only Low, so this is not a critical issue despite the researcher's 'privilege escalation to Owner' framing - the escalation is script execution in a higher-privileged user's session, not direct account takeover. E:P (Proof-of-Concept) is set and a public exploit exists on GitHub, but there is no EPSS score, no CISA KEV listing, and no evidence of active exploitation - so this is 'publicly available exploit code exists,' distinct from real-world weaponization. I disagree with the vendor's PR:H: 'EDIT perm' in Leantime is a mid-tier collaborator capability, not administrative, so PR:L better reflects the low bar to plant the payload; this makes the practical risk slightly higher than the 4.8 suggests but still bounded by the requirement for an authenticated insider and a viewing victim. Net: a real, patch-worthy finding for multi-user Leantime instances, not an emergency.

An authenticated project member with EDIT permission creates or renames a status/label with a malicious script payload as its name. When the project Owner (or any other user) opens the Project Dashboard, show.blade.php echoes the label name raw, executing the attacker's JavaScript in the victim's authenticated session - enabling actions or data access at the victim's privilege level. A public proof-of-concept for this exact issue is available on GitHub (natanmorette-thoropass research repo).