Summary
NocoBase's collection SQL plugin can allow privileged users to store SQL that bypasses the intended checkSQL() validation through the sqlCollection:setFields action. When the affected collection query is reloaded, the stored statements may execute and expose sensitive database information or read server-side files.
NocoBase's collection SQL plugin can allow privileged users to store SQL that bypasses the intended checkSQL() validation through the sqlCollection:setFields action. When the affected collection query is reloaded, the stored statements may execute and expose sensitive database information or read server-side files.
Affected context
The vulnerability occurs in NocoBase deployments using the @nocobase/plugin-collection-sql component through version 2.2.28. It requires a collection configured to use SQL and a workflow in which a user with sufficient privileges can modify the collection's SQL definition through the sqlCollection:setFields action.
The vulnerability occurs in NocoBase deployments using the @nocobase/plugin-collection-sql component through version 2.2.28. It requires a collection configured to use SQL and a workflow in which a user with sufficient privileges can modify the collection's SQL definition through the sqlCollection:setFields action.
Exploit preconditions
- Attack surface: The NocoBase collection SQL plugin and its collection field-management action
- Required access: A privileged account or possession of the relevant collection-sql snippet
- Trigger point: Reloading or otherwise executing the modified collection query
- Why exploitation is possible: SQL supplied through the affected action may bypass
checkSQL()validation and remain stored for later execution
- Attack surface: The NocoBase collection SQL plugin and its collection field-management action
- Required access: A privileged account or possession of the relevant collection-sql snippet
- Trigger point: Reloading or otherwise executing the modified collection query
- Why exploitation is possible: SQL supplied through the affected action may bypass
checkSQL()validation and remain stored for later execution
Why this happens
The underlying flaw is insufficient validation and trust-boundary enforcement for SQL supplied through the sqlCollection:setFields action. A security check intended to reject dangerous statements can be bypassed, allowing attacker-controlled SQL to be persisted as a collection query and executed later. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL injection.
The underlying flaw is insufficient validation and trust-boundary enforcement for SQL supplied through the sqlCollection:setFields action. A security check intended to reject dangerous statements can be bypassed, allowing attacker-controlled SQL to be persisted as a collection query and executed later. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL injection.
Potential impact
- An attacker may read database metadata or credential-related records such as PostgreSQL password hashes.
- An attacker could invoke database functions capable of reading files from the database server.
- Sensitive application data may be disclosed, altered, or deleted.
- Database integrity and the confidentiality of connected services could be affected.
- An attacker may read database metadata or credential-related records such as PostgreSQL password hashes.
- An attacker could invoke database functions capable of reading files from the database server.
- Sensitive application data may be disclosed, altered, or deleted.
- Database integrity and the confidentiality of connected services could be affected.
General mitigation guidance
Mitigation generally focuses on preventing user-controlled SQL from becoming executable database logic.
Common defensive patterns include:
- Prefer predefined, parameterized query operations over accepting raw SQL text.
- Apply allowlist-based parsing and validation at every action that can create or modify SQL.
- Keep validation adjacent to execution and avoid relying solely on checks performed during initial storage.
- Restrict collection SQL administration to the smallest practical set of trusted roles.
- Use database accounts with least-privilege permissions and limit access to sensitive functions and system catalogs.
- Separate application data access from capabilities that can read server-side files.
Mitigation generally focuses on preventing user-controlled SQL from becoming executable database logic.
Common defensive patterns include:
- Prefer predefined, parameterized query operations over accepting raw SQL text.
- Apply allowlist-based parsing and validation at every action that can create or modify SQL.
- Keep validation adjacent to execution and avoid relying solely on checks performed during initial storage.
- Restrict collection SQL administration to the smallest practical set of trusted roles.
- Use database accounts with least-privilege permissions and limit access to sensitive functions and system catalogs.
- Separate application data access from capabilities that can read server-side files.
How teams detect issues like this
Organizations can look for:
- Static-analysis findings where request or action parameters flow into SQL construction or execution.
- Code-review signals involving bypassable validation helpers, raw SQL persistence, or validation performed only before storage.
- Audit events for
sqlCollection:setFields, collection SQL changes, and unexpected query reloads. - Database monitoring alerts for access to PostgreSQL system catalogs, password-hash data, file-reading functions, or unusual administrative statements.
- Policy enforcement that blocks raw SQL configuration unless it passes strict allowlists and receives elevated review.
Organizations can look for:
- Static-analysis findings where request or action parameters flow into SQL construction or execution.
- Code-review signals involving bypassable validation helpers, raw SQL persistence, or validation performed only before storage.
- Audit events for
sqlCollection:setFields, collection SQL changes, and unexpected query reloads. - Database monitoring alerts for access to PostgreSQL system catalogs, password-hash data, file-reading functions, or unusual administrative statements.
- Policy enforcement that blocks raw SQL configuration unless it passes strict allowlists and receives elevated review.
