foreignObject is the hatch where an SVG document hands off to HTML. Mermaid draws a text label by opening one and putting a div inside it, with a p and a span inside that [15]. The obvious fix asks DOMPurify for two allow lists, svg and svgFilters [12]. Neither has an entry for div. DOMPurify drops a tag it does not recognise along with that tag's subtree, so the whole label goes, and the sanitiser is behaving exactly as configured.
Add up the four affected rows of the author's element count [14]. Eleven foreignObject nodes, eleven spans, eleven p nodes, and eleven of the fifteen divs: 44 elements removed across four diagrams [1]. Every one of them is text or a container for text. Boxes, arrows and layout are pure SVG, so they survive [16], and the diagram still draws at the right size in the right place with nothing written in it. There is no exception to catch and no assertion to fail.
The instructive part is that Forem's own HTML scrubber has the same hole. Its allow list is missing foreignObject, along with text, tspan, marker and style, which is why rendering the SVG on the server was never viable even though svg, path and g are permitted [5]. Two allow lists, written by different people against different threat models, both treat the label carrier as unrecognised markup. If your sanitiser and your scrubber were both written against the SVG spec, and your renderer draws text through the HTML escape hatch, this is the default outcome rather than a bug.
That is also the condition for the numbers transferring. Sequence diagrams lost nothing [14], so those labels are not going through foreignObject at all [2]. Run Mermaid with HTML labels off and the svg profile is close to transparent, and the CodeQL one-liner is fine as written. Run the default and four of the five types tested here degrade [16], which means a spot check on one randomly chosen diagram would have surfaced the loss four times in five [3].
The check that caught it is cheap: render a handful of diagrams, sanitize the output, count elements on each side, compare [13]. CodeQL closes either way [12]. And the alert was correct about the shape of the problem, because user-authored diagram source really does reach innerHTML by way of mermaid.render() [9]. The author's reason for not simply leaning on Mermaid's strict mode, which already sanitizes its own output with DOMPurify [10], is that trusting a dependency's internal sanitisation for untrusted input is the pattern behind Mermaid's own historical XSS advisories [11]. I agree with the direction, and the one-liner is still the right shape of fix. It needed the element count sitting next to it before the merge.
