Security fix — attribute escaping in the to-HTML renderers
Anyone using odtToHtml() or odsToHtml() on documents they did not author should upgrade.
Both renderers assembled inline CSS by string interpolation and wrote it into style="…" without escaping. A style value carrying a double quote could therefore terminate the attribute early, letting a crafted .odt or .ods inject markup into the rendered output — output both functions exist to produce for embedding in a page.
Text content and the href, src, alt, id and data-* attributes were already escaped. The style strings were the gap, and they carry values taken verbatim from document styles: colours, fonts, backgrounds, margins, padding, borders, line-height, vertical alignment, and column and row geometry.
Every hand-built attribute in both renderers now escapes its interpolated values, using the escaper the writer side has always used for XML attributes rather than a newly written one. The image src data URI is included — its media type and payload were interpolated unescaped on the same path, and both are now escaped unconditionally.
Accepted input is unchanged and no conversion that previously succeeded now fails. Output differs only where a value contained a character requiring escaping; where it does, the value is preserved as an entity rather than breaking out of its attribute. A regression test covers each site.
Reported through GitHub's private vulnerability reporting by Pethu Kannan G, with reproductions and a suggested fix — thank you. Advisory GHSA-3cgg-c5pp-57h6; it will publish with its CVE shortly now that the fix is available.
Also in this release
The ODT renderer's file header no longer claims its output is "safe to embed in any context." That sentence was wrong in two ways, and the correction matters if you relied on it: escaping prevents markup breakout, but it says nothing about where a URL points, what a CSS value causes a browser to fetch, or what your page's CSP permits. If you embed this output in a page, sanitize it or render it in a sandboxed context.
Markdown parsing corrections arrive with marked 18.0.9. Two default-path fixes change emitted output: an unmatched strong run before emphasis now stays literal (**foo *bar* keeps its asterisks rather than applying bold), and blockquote continuation after a blank line no longer inherits spurious deeper nesting. Both move markdownToOdt output toward CommonMark — documents using these constructs will convert differently than under 0.14.1.
Full detail in CHANGELOG.md.
What's Changed
- deps(deps-dev): bump vnu-jar from 26.7.31 to 26.8.6 by @dependabot[bot] in #85
- deps(deps-dev): bump typescript-eslint from 8.65.0 to 8.66.0 by @dependabot[bot] in #84
- deps(deps): bump marked from 18.0.7 to 18.0.9 by @dependabot[bot] in #83
- deps(deps-dev): bump typescript-eslint from 8.66.0 to 8.70.0 by @dependabot[bot] in #87
- deps(deps-dev): bump eslint from 10.8.0 to 10.10.0 by @dependabot[bot] in #92
- deps(deps-dev): bump vnu-jar from 26.8.6 to 26.9.7 by @dependabot[bot] in #91
- deps(deps-dev): bump esbuild from 0.28.1 to 0.28.2 by @dependabot[bot] in #89
Full Changelog: v0.14.1...v0.14.2
