In general, to fix this class of problems you must either (a) sanitize/escape any HTML you construct from library inputs before inserting it into the DOM, or (b) change the API so that callers provide structured elements instead of raw HTML strings, or (c) clearly document that the function only accepts trusted HTML. Since this is a low-level rendering helper and we should not rely on all callers correctly treating inputs as trusted, the safe approach is to ensure that whatever is inserted into the DOM cannot execute arbitrary scripts.

The single best fix here is to sanitize the result of convertHtml before using it to construct the HTML wrapper string in createDiv. The project already imports htmlEntities from ../../util/StringUtils.js, which suggests it is an escaping helper for HTML. We can apply htmlEntities to the converted HTML string, then place that escaped string inside our wrapper DIVs. That way, any <script> tags or other markup in user-controlled input will be rendered as literal text rather than being interpreted as HTML, while still preserving the current behavior of convertHtml for well-formed inputs. Concretely, in createDiv, instead of:

if (!isNode(val)) {
  val = `<div><div>${this.convertHtml(val)}</div></div>`;
}

we transform the inner string via htmlEntities:

if (!isNode(val)) {
  const safeHtml = htmlEntities(this.convertHtml(val as string));
  val = `<div><div>${safeHtml}</div></div>`;
}

We already have htmlEntities imported at the top of SvgCanvas2D.ts, so no new imports are required. This change localizes the fix to the tainted data flow identified by CodeQL and addresses all alert variants that stem from unsafe HTML reaching div.innerHTML and the nested nodes/foreignObject created from it.