Description

Nuxt Content is the file-based CMS for Nuxt applications, powered by Markdown and Vue components. From 3.0.0 until 3.15.2, the unauthenticated POST /__nuxt_content/:collection/query endpoint accepts an attacker-controlled sql field in src/runtime/api/query.post.ts and permits expensive SQLite expressions. Version 3.0.0 performed no query validation; in affected releases using assertSafeQuery in src/runtime/internal/security.ts, the reported validation gap rejects a short list of SQL command keywords in WHERE clauses but permits function calls including randomblob(), zeroblob(), hex(), and length(). The query reaches the synchronous better-sqlite3 sink in src/runtime/internal/database.server.ts, allowing a single remote request to consume substantial CPU and memory while blocking the Node.js event loop and all concurrent request handling. Fully static prerendered deployments that do not expose the server endpoint are not affected. This issue is fixed in version 3.15.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-11-06T18:17:37.333Z",
  "pubdate": "2026-11-06T18:17:37.333Z",
  "executiveSummary": "Nuxt Content versions 3.0.0 through 3.15.2 are vulnerable to a Denial-of-Service (DoS) condition via the unauthenticated POST /__nuxt_content/:collection/query endpoint.\nThe vulnerability originates from insufficient input sanitization of the 'sql' field within the query handler, which allows an attacker to execute computationally expensive SQLite functions.\nBecause the application utilizes the synchronous 'better-sqlite3' driver, malicious payloads can saturate CPU and memory resources, effectively blocking the Node.js event loop.\nThis behavior results in a complete service outage for all concurrent requests.\nThe vulnerability is exploitable by unauthenticated remote attackers.\nWhile systems employing fully static prerendering without the server-side API endpoint remain secure, any dynamic deployment exposing this endpoint is at high risk of resource exhaustion attacks.\nThe vulnerability was addressed in version 3.15.2 by closing the validation gaps that previously permitted dangerous SQL function calls.",
  "technicalDetails": "The vulnerability resides in the src/runtime/api/query.post.ts endpoint, which acts as an interface for content querying. The underlying issue is an improper validation mechanism located in src/runtime/internal/security.ts within the assertSafeQuery function.\nAlthough the implementation attempts to implement a blacklist of SQL keywords, it fails to account for computationally intensive SQLite built-in functions. Specifically, while standard keywords are restricted, the parser allows functions such as randomblob(), zeroblob(), hex(), and length() to be passed in the 'sql' field of the request body.\nThe attack flow proceeds as follows: an attacker initiates an unauthenticated POST request to /__nuxt_content/:collection/query. The malicious payload embeds these resource-heavy functions into the WHERE clause of the query. Upon receipt, the application passes this input directly to the better-sqlite3 database driver located in src/runtime/internal/database.server.ts.\nBecause better-sqlite3 operates synchronously, the Node.js main thread remains occupied while the SQLite engine performs the requested heavy computations. Functions like randomblob() or nested calls designed to exhaust memory can lock the event loop, preventing the Nuxt server from processing incoming event queue tasks. This stalls all concurrent request handling, leading to a state of total service unavailability.\nThe exploitation does not require administrative privileges or prior authentication, making it a critical risk for dynamic Nuxt Content deployments. The scope of impact is limited to the server instance executing the database queries; however, because the execution is synchronous and blocks the entire thread, a single request is sufficient to trigger the DoS condition.\nThis flaw represents a failure in 'defense-in-depth' within the library's internal security logic, as the sanitization layer assumed that blocking common SQL keywords was sufficient to prevent arbitrary code or high-cost operations, failing to account for the internal complexity and overhead of the SQLite function suite."
}