NocoDB Prototype Pollution: Crashing the Database Party with One JSON Key

NocoDB is a darling of the low-code world, effectively turning any database into a smart spreadsheet (think Airtable, but open source and self-hosted). It's built on a modern Node.js stack, which makes it performant, flexible, and—as it turns out—susceptible to one of JavaScript's most notorious footguns: Prototype Pollution.

While the vulnerability requires org-level-creator privileges (which sounds high, but in many self-hosted instances, is quite common for developers or power users), the impact is disproportionate. We aren't just talking about deleting a row; we are talking about poisoning the water supply of the entire Node.js process. Once the prototype is polluted, every object created subsequently carries the taint, leading to chaos in completely unrelated parts of the application.

The root cause here is a tale as old as time (or at least as old as ES6). The developers needed to merge configuration objects recursively. Instead of reaching for a battle-tested library or using safe primitives, they implemented a custom deepMerge utility in packages/nocodb/src/utils/dataUtils.ts.

Deep merging is deceptively simple. You iterate over keys in a source object and copy them to a target. But if you don't explicitly block keys like __proto__, constructor, or prototype, an attacker can instruct the merge function to step outside the bounds of the target object and modify the blueprint of Object itself.

In this specific case, the deepMerge function blindly walked down the path provided by the user input. When it encountered __proto__, it didn't stop; it modified the global Object.prototype. This means every plain object in the application suddenly inherits whatever garbage property the attacker injected.

Let's look at the logic flaw. While we don't have the exact byte-for-byte original source, the pattern is unmistakable. A vulnerable recursive merge looks something like this:

// The Vulnerable Pattern
const deepMerge = (target, source) => {
  for (const key in source) {
    if (isObject(source[key])) {
      if (!target[key]) Object.assign(target, { [key]: {} });
      deepMerge(target[key], source[key]); // Recursion without checks
    } else {
      // If key is "__proto__", we are writing to Object.prototype!
      Object.assign(target, { [key]: source[key] });
    }
  }
  return target;
}

The fix in version 0.301.0 was decisive. Instead of trying to patch the holes in their custom logic, the NocoDB team ripped it out entirely. They replaced the manual recursion with rfdc (Really Fast Deep Clone) and hardened their expression parsing with nc-jsep.

// The Fix (Conceptual)
import rfdc from 'rfdc';
const clone = rfdc();
 
// rfdc does not copy prototype properties by default
const mergedConfig = clone(userInput);

This is the correct approach: don't write your own crypto, and don't write your own deep merge unless you enjoy reading CVE reports about your code.

To trigger this, an attacker needs access to the /api/v2/meta/connection/test endpoint. This endpoint allows users to test database connection strings. The payload is a JSON object defining the connection parameters.

Here is the payload that brings the server to its knees:

POST /api/v2/meta/connection/test
Content-Type: application/json
 
{
  "client": "mysql",
  "connection": {
    "host": "127.0.0.1",
    "__proto__": {
      "polluted": true,
      "client": "malicious_override"
    }
  }
}

When NocoDB processes this, deepMerge pollutes the global object. Why does this cause a Denial of Service? NocoDB relies on Knex.js for database operations. Knex (and many other libraries) iterates over configuration objects or checks for the existence of specific internal flags.

Once Object.prototype has a property like polluted or specific internal flags modified, Knex throws errors during query construction or connection pooling. Since the Node.js process memory is shared, every single database request from every user will now fail until the server is manually restarted. It is a persistent, zombies-everywhere scenario.

The mitigation strategy employed by the NocoDB team highlights an important lesson in modern software development: dependency management is a security feature.

1. Replace Custom Logic: They swapped the custom merge for rfdc. rfdc is designed to be fast and safe, ignoring prototype properties.
2. Harden Parsers: They moved to a hardened fork of jsep (nc-jsep) to prevent similar injection attacks in their formula/expression evaluation logic.

For administrators running NocoDB, the only real fix is to patch. If you are on a version < 0.301.0, you are sitting on a ticking time bomb—albeit one that requires a somewhat privileged user to detonate.