File Management System EUVD-2026-107394

Exploitation requires reaching the FileController 'store' action that handles the 'File' upload parameter and the absence of server-side validation of file type/extension/content; practical impact (code execution) additionally requires that the storage location be web-accessible and that uploaded files be executed by the server (e.g., PHP handler on the upload directory). Limiting factors: the vector claims PR:N but a file-management 'store' route may require an authenticated session - if so, exploitation needs valid credentials, which is not confirmed from the available data; impact is also constrained if uploads are stored outside the web root or served with a non-executing handler. No specific non-default configuration flag is named in the description.

This is a moderate-priority issue that does not rise to an emergency despite the CWE-434 unrestricted-upload classification. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) indicates remote, low-complexity, unauthenticated exploitation, which argues for urgency; however, the impact metrics are uniformly Low (VC:L/VI:L/VA:L) and exploit maturity is only Proof-of-Concept (E:P), yielding a modest 6.9 score. The NOT in CISA KEV and there is no EPSS value supplied, so widespread or automated exploitation cannot be inferred - the only exploitation signal is a publicly posted GitHub issue (POC), which is a distinct and weaker signal than active exploitation. A key tension: an 'unrestricted file upload' in a file-management application often enables web-shell upload and full server compromise (which would justify High integrity/confidentiality impact), yet both VulDB's 4.0 vector and the brief description cap impact at Low, suggesting either limited reachability of the uploaded file or that the analyst did not confirm code execution - this discrepancy should be verified against the actual code path. Additionally, PR:N (unauthenticated) is asserted by the vector, but a 'store' controller in a file-management product may well sit behind authentication; this is unconfirmed and materially affects real risk.

A remote attacker sends a crafted multipart request to the FileController store endpoint, supplying a malicious file (e.g., a PHP script) via the 'File' argument that the application stores without validating type or extension. If the upload directory is web-accessible and served by the PHP interpreter, the attacker then requests the stored file to achieve code execution; a proof-of-concept has been publicly disclosed in the project's GitHub issue tracker. Given AV:N/AC:L/PR:N, the request requires no special timing, user interaction, or (per the vector) authentication.