Unrestricted File Upload on an EOL Portal

An unrestricted file upload vulnerability accepts any file type from an authenticated user, stores it accessibly, and returns success. There is no content-type validation, no extension allowlist, no magic-byte check, and no isolation of uploaded content from the web root. The upload endpoint on an EOL enterprise portal platform accepted a Windows PE executable renamed with a benign extension, submitted with an application/x-msdownload Content-Type, and returned 200 with a success message. The platform had reached end-of-life with no further security patches.

The upload

The registration submission endpoint accepted multipart file data. Modifying the filename and Content-Type in Burp and uploading a benign PE binary confirmed that the server performs no validation on the uploaded content:

POST /documents/upload HTTP/1.1
Host: portal.acme-lab.test
Content-Type: multipart/form-data; boundary=----LabBoundary

------LabBoundary
Content-Disposition: form-data; name="file"; filename="calc.exe"
Content-Type: application/x-msdownload

MZ...PE binary content...
------LabBoundary--

HTTP/1.1 200 OK
Content-Type: application/json

{"success":true,"processMessage":"Registration submitted","fileId":"lab-file-001"}

# PE binary accepted with application/x-msdownload Content-Type
# no rejection, no quarantine, no content validation
# fileId returned — file retrievable at /documents/lab-file-001

The returned fileId was accessible without authentication from the /documents/ path. An uploaded JSP webshell would be served from the same origin and executed by the application server stack on access. The path from unrestricted upload to remote code execution on the application server is one additional step: upload a JSP file, request it, receive a shell in the application context.

EOL platform amplification

The platform was end-of-life before this assessment. It carries numerous known unpatched CVEs for which no vendor fix exists — remote code execution vulnerabilities in the scripting engine and administrative interfaces that would otherwise be patched. On an EOL platform, every finding that requires an authenticated user is effectively a finding that any attacker who registers an account can exploit. The file upload finding was documented at Critical; the EOL platform status and its associated unpatched CVE exposure are companion findings in the same assessment.

The test timeline

Closing the upload surface

• Validate file content server-side against an allowlist of permitted types. Read and validate the magic bytes for the declared file type — not just the extension or Content-Type header. Reject files that do not fully conform. For user-uploaded documents, a narrow allowlist (PDF, DOCX, XLSX, PNG, JPG) eliminates the attack surface entirely.
• Store uploaded files outside the web root. Files stored in a path served by the web server can be directly requested and executed (JSP, PHP, etc.). Store uploads in a directory the web server cannot serve. Return file content through an application-controlled download handler that sets explicit Content-Type and Content-Disposition headers.
• Serve all user uploads with Content-Disposition: attachment and X-Content-Type-Options: nosniff. Force downloads rather than inline rendering. The nosniff header prevents MIME-type sniffing that allows browsers to execute mis-typed content.
• Migrate off the EOL platform. An end-of-life platform with no remaining security patches is not a risk that can be managed with mitigating controls. The migration timeline should be measured in weeks, not quarters. All known CVEs against an EOL platform are permanently open.

The takeaway

An upload endpoint that accepts everything and stores it in the web root is a webshell waiting to happen. The validation fix is one middleware change. The EOL migration is the harder problem — but it cannot be deferred indefinitely.