CVE-2026-73295: DOM-based Cross-Site Scripting (XSS) in Material for MkDocs Search Suggestions

Material for MkDocs is a static-site-generator-based documentation framework widely adopted for developer portals and documentation sites. The framework provides an optional client-side feature known as search suggestions (search.suggest), which assists users by showing matching queries as they type. This feature relies on client-side JavaScript components to handle real-time search inputs and update the web interface dynamically.

The client-side autocomplete engine utilizes RxJS-based reactive flows to observe search inputs and manipulate the DOM based on user typing or pre-populated URL states. When a user visits a documentation path with the q query parameter, the system automatically parses and processes this string to seed the search input. This mechanism creates an input source that can be manipulated by external, untrusted vectors.

A vulnerability exists in the mountSearchSuggest handler where inputs sourced from this stream are assigned directly to the document structure without verification. Because the input undergoes structural modification rather than sanitization, it introduces a DOM-based Cross-Site Scripting (XSS) threat vector. An attacker can exploit this condition to execute arbitrary JavaScript in the context of the vulnerable host's origin.

The root cause of CVE-2026-73295 resides in the processing pipeline within the mountSearchSuggest function, located in src/templates/assets/javascripts/components/search/suggest/index.ts. The implementation subscribes to an observable stream of words extracted from user search input. Instead of treating this stream as literal text, the original codebase updates the DOM via an unsafe assignment.

The specific code-level sink responsible for this behavior is the .innerHTML property of the target suggestion element (el.innerHTML). Before assignment, the application performs basic transformations: it joins the array of words and replaces all whitespaces with HTML entity-encoded spaces ( ). However, these operations do not filter out HTML tag structures, script blocks, or malformed attributes.

This implementation pattern violates basic secure coding standards regarding DOM manipulation. Since the browser interprets any data passed to .innerHTML as markup, the browser's HTML parser instantiates any executable elements within the payload. If an attacker submits a string containing valid HTML element wrappers with active event handlers, the payload executes.

The comparison between the vulnerable and patched versions reveals how the application was restructured to prevent executable markup insertion. In the vulnerable codebase, the rendering routine joins the input word array and assigns the result directly to the element. The regex replacement was used to preserve space formatting in the client-side autocompletion box.

Below is the vulnerable code block contrasted with the official patch applied in commit 52fb6be8aafe326419f34dc94d3211e7bbfbfb25:

// Vulnerable Implementation (v7.2.0 - v9.7.6)
export function mountSearchSuggest(...) {
  // ...
  .subscribe(words => el.innerHTML = words
    .join("")
    .replace(/\s/g, " ")
  )
  // ...
}
 
// Patched Implementation (v9.7.7)
export function mountSearchSuggest(...) {
  // ...
  .subscribe(words => el.textContent = words.join(""))
  // ...
}

The fix replaces the .innerHTML assignment with .textContent, which instructs the browser to treat the input as a string literal and automatically escape characters like < and >. Because textContent does not render HTML entities, the developers removed the .replace(/\s/g, " ") instruction. To maintain proper layout spacing and prevent consecutive spaces from collapsing, they added a CSS rule white-space: pre inside _search.scss to replace white-space: nowrap.

This modification represents a complete and robust remediation. By avoiding the interpretation of the string as HTML elements, the browser enforces context-appropriate rendering, preventing all forms of DOM-based injection through this channel.

Exploitation of this vulnerability requires the presence of specific conditions and victim interaction. First, the target documentation site must have the optional search.suggest feature enabled within the mkdocs.yml configuration file. Second, the attacker must entice a victim into clicking a specially crafted hyperlink containing the payload within the search query parameter.

Below is a diagram showing the attack propagation vector:

To demonstrate the vulnerability, an attacker can append a standard payload such as <img src=x onerror=alert(document.domain)> to the query parameter. When the victim navigates to the URL, the underlying RxJS stream extracts the payload, replaces the spaces with non-breaking spaces, and writes the string to the DOM. The browser attempts to load the invalid image path, fails, and triggers the onerror event handler, leading to script execution.

The impact of a successful DOM-based Cross-Site Scripting attack is bound to the origin of the hosting documentation site. Under the CVSS v3.1 framework, this vulnerability is scored at 5.4, reflecting a medium severity. The impact is restricted to confidentiality and integrity because the attack runs entirely within the client session.

An attacker executing arbitrary JavaScript can read and exfiltrate sensitive data, such as local storage data, session tokens, or non-HttpOnly cookies. Additionally, the attacker can manipulate the DOM to perform page defacement, insert malicious login overlays, or conduct drive-by downloads. Since MkDocs sites are often used to host private enterprise documentation, this can expose confidential corporate information.

The threat potential is moderated by the requirement for user interaction, as a victim must actively click a link to trigger the vulnerability. According to the Exploit Prediction Scoring System (EPSS), the probability of exploitation remains low, standing at 0.00185. CISA's Known Exploited Vulnerabilities catalog does not currently list this CVE, indicating that active public campaigns targeting this flaw are not widespread.

The primary and recommended resolution is to upgrade the Material for MkDocs installation to version 9.7.7 or later. The upgrade replaces the vulnerable TypeScript file and updates the associated stylesheet to ensure that visual layouts are preserved without introducing security regressions. The package can be updated using standard package managers like pip or through updated container images.

For environments where an immediate package upgrade is not feasible, security administrators can apply a configuration workaround. Disabling the search.suggest feature in the mkdocs.yml configuration file completely removes the vulnerable code path. Administrators should locate the theme.features array and ensure that the search.suggest list item is removed or commented out.

Organizations should also implement a robust Content Security Policy (CSP) on their web servers to limit the impact of unexpected client-side vulnerabilities. A strong CSP that restricts the execution of inline scripts and defines trusted source domains for dynamic scripts acts as a defense-in-depth barrier. This mitigation restricts arbitrary JavaScript from running even if an attacker successfully triggers the DOM injection.