CVE-2026-80050: ContiNew Admin File Upload Vulnerability

CVE-2026-80050 Overview

CVE-2026-80050 affects ContiNew Admin through version 4.1.0. The application fails to apply file-upload permission checks or file-type allowlist validation to its multipart upload endpoints. Authenticated users can initialize chunked uploads, send file parts, and complete uploads to store files with arbitrary extensions in the storage backend. Uploaded files become accessible through web server URLs, enabling attackers to place executable or malicious content in a location reachable by other clients. The vulnerability maps to CWE-434: Unrestricted Upload of File with Dangerous Type.

Critical Impact
Authenticated attackers can upload arbitrary files to the storage backend, undermining integrity of the hosting environment and enabling delivery of hostile content through trusted URLs.

Affected Products

ContiNew Admin through version 4.1.0
MultipartUploadController component within continew-system
Deployments exposing multipart upload endpoints to authenticated users

Discovery Timeline

2026-08-25 - CVE-2026-80050 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-80050

Vulnerability Analysis

ContiNew Admin exposes a chunked upload workflow implemented in MultipartUploadController. The controller accepts three operations: initialize a multipart upload session, send file parts, and complete the upload. None of these operations enforce upload permission checks, and none validate the requested filename or extension against an allowlist. Any authenticated principal can therefore drive the workflow to completion regardless of role. The resulting object is written to the configured storage backend with the attacker-chosen filename, including extensions such as .jsp, .php, or .html. Because the storage backend is fronted by a web server that serves uploaded objects at predictable URLs, the stored file becomes retrievable by any client that knows the path.

Root Cause

The controller relies on the presence of an authenticated session as the sole authorization check. It does not consult a role-based permission for the upload action and does not filter or normalize file extensions before persisting the object. This combination of missing authorization and missing input validation matches the CWE-434 pattern.

Attack Vector

Exploitation requires network access to the application and a valid low-privilege account. The attacker calls the initialize endpoint with a chosen filename, streams part data through the parts endpoint, then calls the complete endpoint. The storage backend writes the finalized object and the web server exposes it at a URL derived from the upload metadata. Refer to the VulnCheck Advisory on ContiNew Admin and the MultipartUploadController source for endpoint specifics.

No verified proof-of-concept code is available at this time. See the GitHub Issue #221 Discussion for community analysis.

Detection Methods for CVE-2026-80050

Indicators of Compromise

Unexpected files with server-executable extensions such as .jsp, .jspx, .php, .html, or .svg in the storage backend directory
Application logs showing multipart upload initialize, part, and complete calls originating from low-privilege accounts
Web server access logs recording GET requests to uploaded object URLs shortly after an upload sequence

Detection Strategies

Audit MultipartUploadController request logs for upload sequences that terminate with non-media extensions
Correlate authenticated session identifiers with upload completion events to identify accounts that should not have upload capability
Compare stored object extensions against an expected content-type baseline for the application

Monitoring Recommendations

Enable verbose logging on the multipart upload endpoints and forward events to a centralized log platform
Alert on new files written to the storage backend outside of change windows
Monitor outbound egress from the application host for callbacks that would indicate execution of an uploaded payload

How to Mitigate CVE-2026-80050

Immediate Actions Required

Restrict network access to the multipart upload endpoints to trusted administrators until a fix is applied
Review existing storage backend contents and remove any files with unexpected extensions
Rotate credentials for accounts that had access to the upload endpoints during the exposure window

Patch Information

No fixed version is referenced in the NVD record at the time of publication. Monitor the ContiNew Admin repository and the GitHub Issue #221 Discussion for upstream remediation. Once the maintainers publish a patched release, upgrade from any 4.1.0 or earlier deployment.

Workarounds

Add a reverse-proxy rule that denies requests to the multipart upload endpoints from non-administrative users
Enforce a server-side extension allowlist at the ingress layer, rejecting requests whose filename metadata carries executable extensions
Configure the storage backend web server to serve uploaded objects with Content-Disposition: attachment and a non-executable MIME type

bash

# Example nginx configuration to block executable extensions on the upload path
location /api/system/multipart-upload/ {
    if ($request_method = POST) {
        # Restrict to administrator source ranges
        allow 10.0.0.0/24;
        deny all;
    }
}

location ~* ^/uploads/.*\.(jsp|jspx|php|phtml|html?|svg)$ {
    return 403;
}