Proxy Endpoint File Upload: Arbitrary File Types Forwarded to

How a Proxy Endpoint Became a Backdoor to Internal Services

A high-severity vulnerability in the web server's proxy endpoint allowed attackers to upload arbitrary files—executables, scripts, polyglot files—and forward them directly to internal AI services without any validation. The endpoint accepted multipart form data containing an image parameter, then immediately relayed it downstream without checking file type, extension, size, or content.

This created a trust boundary violation: the proxy served as a blind pass-through, assuming that all forwarded data was safe. In reality, an attacker could bypass external firewalls and upload a .exe, .sh, or specially crafted polyglot file into the internal network where AI services would receive and process it.

Affected Versions

The Vulnerability Explained

The proxy endpoint's request handler accepted file uploads via the image parameter in multipart form data:

data = request.form.get('data')
image = request.files.get('image')

# Forward the request to the target server
# (no validation between retrieval and forwarding)

Once retrieved, the file was forwarded to a downstream service with zero inspection. An attacker could exploit this in several ways:

Attack Scenario 1: Direct Executable Upload

An attacker crafts a POST request to the proxy endpoint:

POST /proxy/service HTTP/1.1
Content-Type: multipart/form-data; boundary=----Boundary

------Boundary
Content-Disposition: form-data; name="image"; filename="photo.exe"
Content-Type: application/octet-stream

[binary executable code]
------Boundary--

The endpoint receives the .exe file, sees no reason to reject it, and forwards it to an internal AI service. If that service has logic to execute or process files by extension, the attacker has achieved arbitrary code execution inside the network.

Attack Scenario 2: Polyglot File

An attacker embeds an executable payload inside a valid JPEG file, names it image.jpg, and sets the MIME type to image/jpeg. The endpoint validates neither content nor signature, so both the file extension and MIME type appear legitimate. Downstream services that parse "images" may execute the embedded payload if they use unsafe deserialization or dynamic execution.

Attack Scenario 3: Script Upload

An attacker uploads a Python script as script.py with MIME type text/plain. If the downstream AI service has a code execution path (e.g., a plugin loader or eval-based configuration parser), the uploaded script runs with the service's privileges.

Real-World Impact

• Lateral movement: An attacker on the internet exploits this to drop malware into an internal AI service network, then pivots to other systems.
• Data exfiltration: Malicious scripts uploaded to an AI service can access model weights, training data, or internal credentials stored on disk.
• Service disruption: Polyglot files or resource bombs sent to multiple concurrent AI instances exhaust memory and CPU, causing denial of service.

The vulnerability is particularly dangerous because the proxy endpoint acts as a trust bridge between the public internet and internal services that may not expect hostile input.

The Fix

The fix adds four layers of validation before accepting an upload:

1. MIME type whitelist: Only image/jpeg, image/png, image/gif, image/bmp, image/webp are allowed.
2. File extension whitelist: Only .jpg, .jpeg, .png, .gif, .bmp, .webp suffixes are accepted (case-insensitive).
3. Per-file size limit: Uploaded images must not exceed 10 MB.
4. Early rejection: If validation fails, the endpoint returns a 400 error and does not forward the file.

Here's the updated code:

if image is not None:
    # Only allow genuine, size-limited images to be forwarded to
    # internal AI services so arbitrary executables/scripts cannot
    # be uploaded through this proxy.
    allowed_mimetypes = {'image/jpeg', 'image/png', 'image/gif', 'image/bmp', 'image/webp'}
    allowed_extensions = ('.jpg', '.jpeg', '.png', '.gif', '.bmp', '.webp')
    filename = (image.filename or '').lower()
    if image.mimetype not in allowed_mimetypes or not filename.endswith(allowed_extensions):
        return jsonify({'error': 'unsupported image type'}), 400

    image.stream.seek(0, os.SEEK_END)
    image_size = image.stream.tell()
    image.stream.seek(0)
    if image_size > 10 * 1024 * 1024:
        return jsonify({'error': 'image too large'}), 400

Why both checks?

• MIME type alone can be spoofed by setting the Content-Type header to image/jpeg even if the file is an executable.
• Extension alone can be bypassed by renaming a .exe to .jpg.
• Together, they make it significantly harder to craft a polyglot file that passes both checks. A file must be a genuine image and have a whitelisted extension.

Size validation protects against resource exhaustion: large files consume disk I/O, memory for buffering, and network bandwidth, which can degrade the AI service's availability.

Early rejection ensures that invalid files never reach downstream services, maintaining a clear security boundary.

How Orbis AppSec Detected This

Source: The image parameter from the multipart form data request (request.files.get('image')).

Sink: The downstream service call that forwards the file without intermediate validation.

Missing control: No validation of the file's MIME type, extension, content signature, or declared type against an allowed list before forwarding.

CWE: CWE-434 (Unrestricted Upload of File with Dangerous Type) — a file upload endpoint that accepts files without checking their type or content, allowing dangerous file types (executables, scripts) to be stored or propagated.

Fix: Add a whitelist of allowed MIME types and file extensions; validate the file size; reject any upload that does not match both the MIME type and extension whitelists.

Orbis AppSec detected this vulnerability automatically. Try Orbis AppSec on your repositories to find and fix issues like this.

Conclusion

Proxy endpoints are trust boundaries: they sit between untrusted clients and internal services that may not expect hostile input. Never blindly forward user-supplied files without validating their type, extension, and size. This fix demonstrates that a small amount of validation—whitelisting both MIME type and file extension, plus enforcing a size limit—can eliminate a high-severity vulnerability and prevent malicious code from reaching internal systems. Apply this pattern to any endpoint that accepts file uploads and forwards them downstream.