CVE-2026-84701 in NocoBase
Summary
by MITRE • 09/02/2026
NocoBase fails to sanitize rich text field values in the read renderer, allowing users with create permissions to store malicious HTML with event handlers. Attackers can write arbitrary markup through the collection API that executes in the browsers of all users viewing the affected record.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in NocoBase represents a significant security flaw within its rich text field processing logic, specifically located in the read renderer component. This issue stems from an insufficient sanitization mechanism when handling user-supplied input that is intended to be rendered as rich content. While many modern web applications employ strict Content Security Policies or robust HTML filtering libraries to prevent malicious code execution, NocoBase’s implementation fails to adequately strip dangerous attributes and event handlers from the markup provided by users with create permissions. This oversight allows attackers to inject arbitrary HyperText Markup Language containing executable JavaScript events directly into database records through the collection API. The core technical failure lies in the disparity between how data is ingested during creation versus how it is rendered for display, creating a classic pathway for persistent cross-site scripting attacks where trusted content becomes a vector for malicious code execution.
From an operational perspective, this vulnerability enables stored Cross-Site Scripting scenarios that can severely compromise user sessions and sensitive application data. When a victim with appropriate viewing permissions accesses a record containing the injected payload, their browser executes the embedded JavaScript in the context of the NocoBase domain. This allows attackers to perform actions such as stealing session cookies or authentication tokens, hijacking user accounts, performing unauthorized administrative actions on behalf of the victim, or defacing the application interface. Because the malicious content is stored within the database itself, it persists until manually removed by an administrator, meaning every subsequent viewer of that record becomes a potential target without needing any further interaction from the attacker beyond the initial injection. This persistence amplifies the impact significantly compared to reflected XSS variants and can lead to widespread compromise if high-privilege users are targeted.
The technical classification of this flaw aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. Specifically, it falls under subcategories related to the lack of output encoding or sanitization for dynamic content. In terms of offensive security frameworks, this vulnerability maps directly to MITRE ATT&CK technique T1059.007, which covers JavaScript execution within web browsers. The attack vector leverages the application’s own rendering engine against its users, exploiting trust relationships between the user and the NocoBase instance. By embedding event handlers such as onerror or onload attributes into HTML tags like img or body, attackers bypass standard input validation checks that might only look for script tags, demonstrating a sophisticated evasion of basic security controls often found in low-code platforms where flexibility is prioritized over strict content restrictions.
To mitigate this risk, immediate remediation should focus on implementing rigorous server-side sanitization for all rich text inputs before they are persisted to the database or rendered by the client. Developers must utilize established HTML sanitization libraries such as DOMPurify with a restrictive configuration that explicitly blocks event handlers and dangerous protocols like javascript: in href attributes. Additionally, applying Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts can be loaded and executed, thereby neutralizing many inline script attacks even if they slip through initial filters. Input validation should also enforce allowlists for permitted HTML tags rather than relying on blocklists, ensuring that only expected formatting elements are preserved while all other potentially executable markup is stripped or escaped. Regular security audits of the rendering pipeline and continuous integration testing with fuzzing tools can help identify similar sanitization gaps in future updates to the platform.