Mar 31, 2026·7 min read·2 visits
A DOM-based XSS flaw in baserCMS < 5.2.3 allows JavaScript execution when dynamically rendering newly created blog tags via an unsafe jQuery `.html()` sink.
baserCMS versions prior to 5.2.3 contain a DOM-based Cross-Site Scripting (XSS) vulnerability within the administrative dashboard's tag creation functionality. The vulnerability stems from the unsafe handling of JSON API responses using jQuery's `.html()` method, allowing attackers to execute arbitrary JavaScript in the context of an administrator's session.
baserCMS is an open-source website development framework that provides administrative interfaces for content management. Within the blog management component of this administrative dashboard, users with appropriate privileges can dynamically create and assign tags to blog posts. This functionality relies on asynchronous JavaScript (AJAX) to communicate with the backend API and update the Document Object Model (DOM) without requiring a full page reload.
The vulnerability is classified as a DOM-based Cross-Site Scripting (XSS) issue, tracked under CWE-79 and CWE-116. It occurs because the client-side JavaScript receives input from the server and immediately writes it to the page using an unsafe DOM sink. In this specific application context, the vulnerability manifests within the administrative dashboard, meaning any executed payload runs with the privileges of the active user managing the blog content.
DOM-based XSS differs from reflected or stored XSS because the vulnerability exists entirely in the client-side code rather than the server-side response. While the server does return the attacker-controlled string, the actual execution trigger happens only when the browser's JavaScript engine parses that string as HTML. This mechanism bypasses many server-side XSS filters that do not account for client-side rendering vulnerabilities.
The root cause of this vulnerability lies in the improper handling of user-controlled data within a jQuery DOM manipulation function. Specifically, the application logic responsible for the "Add Blog Tag" feature utilizes the .html() method to insert the name of a newly created tag into a newly generated label element. The vulnerable code path resides in plugins/bc-admin-third/src/bc_blog/js/admin/blog_posts/form.js.
When a user adds a new tag, the frontend application sends a request to the bc-blog/blog_tags/add.json endpoint. The server responds with a JSON object containing the tag's metadata, including the unescaped tag name. The JavaScript success callback then dynamically constructs a new checkbox and label pair to represent this tag in the user interface.
The structural flaw occurs when the script assigns the tag name to the label. By passing result.blogTag.name directly into jQuery's .html() function, the application instructs the browser to parse the string as HTML markup rather than plain text. If the tag name contains valid HTML tags or JavaScript event handlers, the browser's HTML parser will evaluate and execute them upon insertion into the DOM.
The vulnerability is localized to a single file within the application's JavaScript assets. The flaw demonstrates a common anti-pattern in single-page applications and AJAX-heavy interfaces where developer assumptions about data safety lead to unsafe DOM rendering.
The following snippet demonstrates the vulnerable code block prior to the patch. The application constructs a jQuery object representing a <span> element, appends an <input> element, and then appends a <label> element. The critical error happens on the final line of this sequence, where the .html() method processes the unescaped data.
// Vulnerable code in plugins/bc-admin-third/src/bc_blog/js/admin/blog_posts/form.js
success: function (result) {
if (result) {
let checkbox = $('<span class="bca-checkbox"/>')
.append($('<input type="checkbox" name="blog_tags[_ids][]" class="bca-checkbox__input" />')
.val(result.blogTag.id)
.attr('id', 'blog-tags-ids-' + result.blogTag.id))
.append($('<label class="bca-checkbox__label">')
.attr('for', 'blog-tags-ids-' + result.blogTag.id)
.html(result.blogTag.name)); // <--- VULNERABLE SINK
$("#BlogTags").append(checkbox);
}
}The vendor resolved this vulnerability in commit 9f0b62481156c5457262981f8ab28cb5aa1d3f6e. The patch replaces the unsafe .html() method with the safe .text() method. Under the hood, jQuery's .text() method uses the browser's native textContent or innerText properties, or explicitly creates a text node using document.createTextNode(). This instructs the browser to treat the input strictly as literal string content, automatically neutralizing any HTML entities and preventing the execution of embedded scripts.
--- a/plugins/bc-admin-third/src/bc_blog/js/admin/blog_posts/form.js
+++ b/plugins/bc-admin-third/src/bc_blog/js/admin/blog_posts/form.js
@@ -119,7 +119,7 @@ $(function () {
.attr('id', 'blog-tags-ids-' + result.blogTag.id))
.append($('<label class="bca-checkbox__label">')
.attr('for', 'blog-tags-ids-' + result.blogTag.id)
- .html(result.blogTag.name));
+ .text(result.blogTag.name));
$("#BlogTags").append(checkbox);Exploiting this DOM-based XSS vulnerability requires the attacker to inject a malicious payload into the tag creation workflow. The primary prerequisite is that the attacker must have the ability to trigger the creation of a new blog tag, or they must convince an authenticated administrator to interact with a crafted link or perform an action that triggers the payload.
The attack begins with the formulation of an HTML payload designed to execute JavaScript upon rendering. Because the payload is inserted directly into the DOM via .html(), standard image vector payloads are highly effective. An attacker would supply a string such as <img src=x onerror=alert(document.domain)> into the tag name input field.
Once the input is submitted, the frontend sends the POST request to the API. The server records the new tag and replies with a JSON response containing the literal string <img src=x onerror=alert(document.domain)>. The vulnerable client-side code receives this JSON, extracts the string, and passes it to the label's .html() method. The browser immediately attempts to render the <img> tag, fails to load the source x, and fires the onerror event handler, executing the provided JavaScript payload within the victim's session.
The execution of arbitrary JavaScript within the context of the baserCMS administrative dashboard carries significant security implications. The vulnerability is rated High (CVSS 7.1) due to the scope change and the potential for privilege abuse. Because the payload executes in the browser of an authenticated administrator, the attacker gains the ability to perform actions on behalf of that user.
The most immediate threat is session hijacking. If session tokens are not protected by the HttpOnly flag, the JavaScript payload can extract the administrator's cookies and transmit them to an external server controlled by the attacker. This allows the attacker to impersonate the administrator from their own machine without requiring credentials.
Beyond session theft, the JavaScript payload can directly interact with the baserCMS REST API. An attacker can write a payload that silently issues subsequent AJAX requests to create new administrative accounts, alter site configurations, or modify page templates to embed persistent backdoors. This escalation path turns a localized client-side execution vulnerability into a full system compromise, limited only by the privileges of the victim user.
The primary remediation for CVE-2026-32734 is to upgrade the baserCMS installation to version 5.2.3. This version contains the official patch that correctly utilizes the .text() method for DOM insertion, neutralizing the injection vector. System administrators should verify the version number in the CMS dashboard after applying the update to ensure the patch was successful.
In addition to the software upgrade, implementing a robust Content Security Policy (CSP) provides an essential defense-in-depth layer against XSS attacks. A strictly configured CSP that disables inline scripts (script-src 'self') and restricts external resource loading prevents the browser from executing the malicious onerror handler or exfiltrating data, even if the underlying DOM manipulation flaw remains unpatched.
Development teams managing baserCMS deployments should also conduct internal audits of custom plugins or themes. The anti-pattern of passing unvalidated API responses into .html(), .append(), or innerHTML is common. Developers must standardize on using .text() or textContent whenever handling dynamic data originating from users or external APIs to systematically eliminate this class of vulnerabilities.
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L| Product | Affected Versions | Fixed Version |
|---|---|---|
baserCMS baserproject | < 5.2.3 | 5.2.3 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-79 |
| Attack Vector | Network |
| CVSS Score | 7.1 |
| EPSS Score | 9.54% |
| Impact | Administrative Session Compromise |
| Exploit Status | Proof-of-Concept |
| KEV Status | Not Listed |
Improper Neutralization of Input During Web Page Generation