Chamilo LMS CVE-2026-45144

The attacker must hold at least a ROLE_STUDENT account to write HTML into their own profile fields (firstname, lastname, competences, openarea, teach, diplomas); if the instance has self-registration enabled, an otherwise anonymous attacker can obtain that role, effectively making this exploitable pre-auth. The vulnerable path is the anonymously reachable GET /user/{username}, which renders those fields inside {% autoescape false %} with no server-side sanitization on the write path. Exploitation is limited to Chamilo LMS versions 2.0.0 up to (but not including) 2.0.1, and requires victim interaction: a visitor (potentially an administrator) must follow the public profile link for the stored payload to fire. Deployments that disable self-registration raise the bar to an authenticated student account; the fix in 2.0.1 (updating is the vendor's remediation) removes the autoescape block and sanitizes the fields.

This is a credible, above-average-priority issue rather than an inflated high-CVSS score. The CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:L, 8.9) is well supported by the evidence: a stored XSS (CWE-79) where six user-editable profile fields are rendered inside {% autoescape false %} with no write-path sanitization, confirmed by the vendor commit diff. The scope change (S:C) and high confidentiality/integrity reflect that the payload executes in any visitor's browser - including administrators - enabling account takeover via session/JWT/localStorage theft. PR:L (an attacker needs at least a ROLE_STUDENT account) is a genuine limiter, but the description notes self-registration, when enabled, lets an anonymous attacker obtain that role, which is why the GHSA titles it 'Pre-auth stored XSS'; whether a given deployment is effectively pre-auth depends on that configuration. UI:R is also a real limiter - a victim must follow the public profile link. No EPSS score and no KEV status were provided, and the references contain only the vendor advisory, fix commit, and release - no PoC/exploit reference - so there is no public exploit identified. The vuln.today Decision label is 'this_week' (not act_now/emergency), consistent with a serious-but-not-actively-exploited flaw. One conflict to verify: the description and fix both say versions 2.0.0 up to (not including) 2.0.1, yet the advisory text states the bug was 'Verified live on Chamilo 2.1.0 (commit b543d3a)' - confirm the true affected range with the vendor.

An attacker registers (or uses an existing ROLE_STUDENT account; self-registration, if enabled, makes this trivial) and plants an HTML/JavaScript payload in profile fields such as competences, openarea, teach, or diplomas. They then distribute the public link /user/<attacker> via a forum post, shared link, or staff-onboarding context; when an administrator or other visitor opens it, the script runs in their session and exfiltrates their session cookie, JWT, or localStorage to the attacker, leading to account takeover. No public exploit code is identified, but the mechanism is fully documented in the vendor advisory and fix commit.