CVE-2026-82524 in UnoPim
Summary
by MITRE • 09/02/2026
UnoPim before 2.1.5 contains an authenticated file upload vulnerability that allows authenticated administrators to upload arbitrary PHP files through the TinyMCE image upload endpoint due to missing file extension and MIME type validation. Attackers can upload a PHP web shell to the public storage disk and execute arbitrary operating system commands on the server by accessing the uploaded file at the URL returned in the server response.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in UnoPim versions prior to 2.1.5 represents a critical authenticated remote code execution flaw rooted in insufficient input validation during file upload operations. Specifically, this issue affects the TinyMCE image upload endpoint, which is designed to handle media assets for content management but fails to enforce strict security controls on the files being submitted by administrators. Because the vulnerability requires authentication, it targets users with administrative privileges who possess the necessary credentials to access the application's backend interface and initiate file uploads through the rich text editor components integrated into the platform.
The technical core of this flaw lies in the absence of rigorous validation mechanisms for both file extensions and MIME types during the upload process. When an administrator attempts to insert an image via TinyMCE, the server accepts the uploaded data without verifying that the file is actually a valid image format or checking if its extension matches the expected content type. This lack of sanitization allows attackers who have compromised administrative credentials to bypass standard security expectations by uploading files with executable extensions such as PHP instead of legitimate image formats like JPEG or PNG. The application processes these uploads and stores them in publicly accessible directories without filtering out potentially malicious code embedded within the file headers or body.
Once a malicious PHP web shell is successfully uploaded, it resides on the server's public storage disk where it can be accessed via HTTP requests. By navigating to the specific URL returned by the server response after the upload completes, an attacker gains direct execution capabilities for arbitrary operating system commands through the interpreted PHP code within the web shell. This transforms a simple file management feature into a powerful attack vector that compromises the integrity and confidentiality of the underlying infrastructure. The ability to execute OS-level commands effectively grants full control over the application server, enabling data exfiltration, lateral movement across internal networks, or complete system compromise depending on the privileges under which the web service operates.
From an industry standard perspective, this vulnerability aligns with CWE-434 Unrestricted Upload of File with Dangerous Type and CWE-79 Cross-site Scripting if reflected output is involved, though in this case the primary concern is remote code execution via file upload flaws often categorized under CWE-501 Trust Boundary Violation. In terms of adversary tactics as defined by MITRE ATT&CK, this scenario maps to T1505 Web Shell and T1059 Command and Scripting Interpreter, illustrating how attackers leverage legitimate administrative functions to establish persistent access and execute malicious scripts on compromised systems.
Mitigation strategies must focus on implementing strict server-side validation for all file uploads regardless of the user's authentication level or role within the application. Developers should enforce allowlisting of permitted file extensions rather than relying on deny lists which can be easily bypassed through obfuscation techniques such as double extensions or null byte injection. Additionally, MIME type verification must be performed by inspecting actual file content signatures rather than trusting client-supplied headers which are trivial to spoof. Uploaded files should also be stored outside of publicly accessible web roots whenever possible, and if public access is required for media assets, they should be served with appropriate Content-Type headers that prevent browser interpretation as executable code or processed through a secure image manipulation library that strips metadata and re-encodes images to remove any embedded scripts.