GHSA-qv4m-m73m-8hj7: Authenticated Arbitrary File Upload leading to Remote Code Execution in NotrinosERP

The Human Resource Management (HRM) module of NotrinosERP contains a critical file upload interface within the employee profile documents section. This interface is accessible to authenticated users who possess the "Manage Employees" (SA_EMPLOYEE) privilege. The purpose of this module is to allow HR coordinators to attach administrative and identification documents to individual employee profiles.

The backend handling of these file uploads presents an unconstrained attack surface. It accepts files directly from the user's multipart HTTP POST request and writes them into a public directory within the application's web root. There is no access control mechanism or routing gateway protecting these files once they are written to disk.

The primary vulnerability is classified as CWE-434 (Unrestricted Upload of File with Dangerous Type). By exploiting this flaw, an attacker can upload executable scripts, such as web shells, and trigger their execution by requesting the file directly via HTTP. This leads to immediate and complete remote code execution under the privileges of the web server's operating system process.

The fundamental flaw resides within the script "hrm/manage/employees.php" inside the "tab_documents()" function. In NotrinosERP version 1.0.0, the handler responsible for processing the employee document form fails to execute any validation on the client-supplied filename or file content. It relies on the raw "$_FILES['doc_file']['name']" variable to determine the destination filename on the server.

Unlike other upload functions within NotrinosERP—such as the profile photo uploader, which enforces image format verifications, or the core attachment engine in "includes/ui/attachment.inc", which generates random, extensionless files on disk—this specific HRM handler bypasses all security layers. It builds the target filesystem path by concatenating the upload directory with the unsanitized, user-provided filename.

Furthermore, the destination directory "/company/0/documents/employees/" is fully web-accessible. The root ".htaccess" file only restricts files ending in specific administrative extensions such as ".inc", ".po", or ".sh". It does not contain rules to block the execution of PHP scripts inside the "/company" tree, allowing the web server to interpret and execute any PHP files written to this path.

The vulnerable code execution flow can be traced directly within the document upload handler. The following block highlights the exact mechanism where the unsanitized input is processed and written to the filesystem.

// hrm/manage/employees.php (Release 1.0.0, Lines 568-573)
$upload_dir = company_path().'/documents/employees';
if (!file_exists($upload_dir))
    mkdir($upload_dir, 0777, true);
 
// Vulnerable path construction using unvalidated client filename
$file_path = $upload_dir.'/'.$employee_id.'_'.time().'_'.$_FILES['doc_file']['name'];
 
// File written to the web root without further inspection
if (!move_uploaded_file($_FILES['doc_file']['tmp_name'], $file_path)) {
    // error handling
}

The variable "$file_path" is constructed by directly appending the client-provided file name. Because there is no call to a sanitization function or an extension check, an attacker can control both the file extension and the path layout. On PHP environments that do not automatically strip path traversal sequences from file upload names, an attacker could inject "../" directory traversal characters, leading to a secondary CWE-22 vulnerability.

Additionally, a secondary stored Cross-Site Scripting (XSS) vulnerability (CWE-79) exists in the rendering code within "hrm/includes/ui/employee_ui.inc". The application stores the "$file_path" in the database and echoes it directly inside the "href" attribute of an anchor tag without applying any HTML entity encoding.

// hrm/includes/ui/employee_ui.inc (Lines 153-154)
// Vulnerable output rendering
echo "<a href='" . $file_path . "' target='_blank'>View</a>";

An attacker must first authenticate and obtain a valid session cookie possessing the "SA_EMPLOYEE" permission. The attack requires a valid CSRF token, which can be acquired by querying the document tab. A "GET" request is sent to the employee page to extract the "_token" parameter from the HTML form.

With the CSRF token in hand, the attacker constructs a multipart form-data "POST" request to upload the payload. The payload is a standard PHP web shell embedded within the "doc_file" parameter, with the filename set to "shell.php".

Because the application writes the final file path back to the user interface, the attacker does not need to guess the generated UNIX timestamp. The attacker reads the generated URL directly from the "View" link inside the HTTP response, then navigates to the uploaded script to execute arbitrary commands on the hosting server.

The impact of this vulnerability is critical, carrying a CVSS score of 8.8. Successful exploitation grants the attacker full remote code execution in the context of the user running the web server daemon, typically "www-data" or a dedicated low-privilege service account.

From this position, the attacker can read sensitive configuration files, including database credentials stored in the application's configuration path. This access can be leveraged to extract ERP data, manipulate financial or employee records, or escalate privileges on the host system depending on local OS configurations.

Furthermore, because the target directories are web-accessible and lacked restrictive access control headers or ".htaccess" configuration blocks, the backdoor remains persistently available. The system's integrity, availability, and confidentiality are completely compromised if an unauthorized operator executes command shells on the backend.

To remediate this vulnerability, developers must restructure the document upload logic. The application must avoid using user-controlled names for the direct filesystem storage path. Developers should generate random, extensionless identifiers (such as a UUID or "uniqid()") on the backend, and map these identifiers to the original filenames in a secured database table.

An alternative mitigation involves configuring the web server to deny script execution in the upload directory. For Apache servers, an ".htaccess" file should be deployed inside the "/company/0/documents/" directory to block the PHP interpreter. This prevents the server from executing scripts even if they are successfully uploaded.

# Disable engine execution in the upload folder
php_admin_flag engine off
RemoveHandler .php
SetHandler none

The ideal secure architecture pattern requires moving the upload storage directory completely outside of the web server's document root. Files should be retrieved and served exclusively through an application routing gateway that validates authorization and streams the file using proper content-disposition headers.