The analysis started by fetching the commit information for the provided patch URL. The commit b61dff84851c45369cf931db5bd93db177c657f6 modified the file ui/src/util/extendHeading.js. The core of the vulnerability, as described ("XSS via headers even when no-html is set"), was located in how the extendHeading function set up a custom rendering rule for markdown headings (md.renderer.rules.heading_open).

Specifically, the previous implementation of this rule would create an anchor link for headings. The text content for this anchor link was derived from the header's inline content (label = children.reduce((acc, t) => acc + t.content, '')). This label was then directly assigned to the content property of a new Token of type html_inline. Using html_inline tokens tells markdown-it to pass the content through as raw HTML. This meant that if a header contained an XSS payload (e.g., <h1><img src=x onerror=alert(1)></h1>), the payload within the label would be rendered as HTML, even if the no-html option was enabled in markdown-it (which should prevent such rendering).

The patch rectifies this by no longer creating an html_inline token with the concatenated label. Instead, it preserves the original child tokens of the heading (const originalChildren = children.slice()) and wraps these original tokens with link_open and link_close tokens. This ensures that the actual content of the heading (which forms the link text) is processed by markdown-it's standard rendering pipeline, which correctly applies sanitization rules like no-html.

The function extendHeading is identified as the vulnerable function because it is the entry point in this file that defines and applies this flawed rendering rule. During exploitation, when a markdown document with a malicious header is parsed and rendered, the vulnerable logic within the md.renderer.rules.heading_open callback, established by extendHeading, would be executed.