NocoBase SQL Collection Plugin EUVD-2026-28318

Requires authenticated access with collection management permissions, specifically the pm.data-source-manager.collection-sql permission scope in NocoBase's role-based access control system. This permission level is typically granted to users responsible for data modeling and schema management, not just full system administrators. Default NocoBase installations do not grant this permission to regular users, but many organizations delegate collection management to departmental admins or power users. No special database configuration is required - the vulnerability affects all database backends (PostgreSQL, MySQL, SQLite) supported by NocoBase, though impact varies by database (PostgreSQL enables filesystem access via pg_read_file, MySQL via LOAD_FILE). Network access to the NocoBase API is required (AV:N). No user interaction needed once authenticated (UI:N). Exploitation is NOT limited by non-default configurations - any deployment with the SQL collection plugin enabled and collection management permissions delegated beyond fully trusted DBAs is exploitable.

CVSS 7.2 (High) with vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H reflects network-accessible exploitation requiring high privileges (collection management role). Attack complexity is low once the attacker has the required permission scope (pm.data-source-manager.collection-sql). No EPSS or KEV data provided, suggesting no confirmed active exploitation at time of analysis. Public exploit code exists in the form of the detailed PoC with working curl commands demonstrating the full attack chain from benign collection creation through malicious update to data exfiltration. Real-world risk assessment depends heavily on privilege boundaries: in environments where collection managers are treated as semi-trusted users (common in low-code platforms with delegated data modeling), this represents critical risk because it enables privilege escalation from data modeling permissions to full database read access and potential filesystem access via pg_read_file/LOAD_FILE. The vendor-provided patch (GitHub PR #9134) is straightforward, indicating the fix is non-breaking. Priority should be HIGH for NocoBase deployments with multiple administrative tiers where collection management is delegated to users who should not have direct SQL execution privileges. The presence of detailed PoC and simple exploitation path increases urgency despite the high privilege prerequisite.

An attacker with collection management permissions (often granted to data modelers or departmental admins in NocoBase deployments) authenticates to the platform and creates a SQL collection named 'reports' with benign SQL like 'SELECT 1 as id' that passes checkSQL validation. Minutes later, they issue an update request to the sqlCollection:update endpoint, modifying the SQL to 'SELECT id, email, password FROM users' with matching field definitions. The update bypasses all validation. The attacker then queries the collection via the standard API endpoint /api/reports:list, receiving JSON containing all user records including bcrypt password hashes. On PostgreSQL deployments, the attacker can escalate to filesystem access using 'SELECT pg_read_file('/etc/passwd')' or lateral database movement via dblink(). Public PoC with working curl commands exists in the security advisory.