CVE-2026-113787 in odf-kit
Summary
by MITRE • 10/22/2026
odf-kit allows users to generate, fill, read, and convert OpenDocument Format files (.odt, .ods) in TypeScript and JavaScript. Starting in version 0.10.0 and prior to version 0.14.2, he renderer has an `escapeHtml()` helper and applies it consistently to text content and to attribute values — `href`, `src`, `alt`, `id`, `data-author`, `data-date`, citation text all go through it. The inline CSS strings do not. In `renderTextSpan` (`dist/odt/to-html/html-renderer.js:195`), the value of e.g. `fo:color` is copied from the document into `style.fontColor` verbatim by the parser (`extractSpanStyle`, read/parser.js:348), then concatenated raw into the attribute. A `"` in the value terminates the attribute early. The same unescaped `style="${...}"` pattern appears at roughly ten other emission sites: paragraph and heading (`paragraphStyleToCss`), table cells and rows (`cellStyleToCss`, `rowStyleToCss`), `<col>`, and the image style attribute. The affected source attributes include `fo:color`, `fo:background-color`, `fo:text-shadow`, `fo:letter-spacing`, `fo:font-family` (via both direct and font-face resolution), `fo:margin-*`, `fo:padding-*`, `fo:line-height`, `fo:border*`, and `style:vertical-align`. Version 0.14.2 contains a patch.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in odf-kit versions starting from 0.10.0 up to but not including 0.14.2 represents a significant Cross-Site Scripting risk rooted in inconsistent input validation and output encoding within the library's HTML rendering engine. As a widely used tool for generating, filling, reading, and converting OpenDocument Format files such as .odt and .ods documents into web-compatible formats, odf-kit processes user-supplied content that may contain malicious payloads. The core of the issue lies in the disparity between how different types of data are handled during the conversion process. While text content and specific attribute values like href, src, alt, id, and citation texts are correctly passed through an escapeHtml helper to neutralize special characters, inline CSS strings derived from document styles are rendered without any sanitization or encoding. This inconsistency creates a direct pathway for attackers who can influence style attributes within the source OpenDocument files to inject arbitrary JavaScript code into the resulting HTML output.
The technical mechanism of this flaw is located in the rendering logic, specifically within functions such as renderTextSpan and various style-to-CSS converters like paragraphStyleToCss, cellStyleToCss, and rowStyleToCss. When parsing styles from an OpenDocument file, attributes such as fo:color, fo:background-color, fo:text-shadow, fo:letter-spacing, fo:font-family, margin properties, padding properties, line-height, border definitions, and vertical alignment are extracted verbatim by the parser without validation. These raw values are then concatenated directly into HTML style attributes using a pattern like style="${...}". Because standard CSS attribute values do not require escaping for most characters except quotes in certain contexts, this approach fails to account for malicious inputs containing double quotation marks or other delimiters that can break out of the intended context. For instance, if an attacker sets fo:color to a value ending with a quote followed by JavaScript code and another quote, they can terminate the style attribute prematurely and inject executable script tags into the DOM. This behavior is characteristic of CWE-79, which classifies improper neutralization of input during web page generation as Cross-site Scripting.
The operational impact of this vulnerability allows for severe security consequences depending on how odf-kit is integrated into an application. If a service accepts uploaded OpenDocument files and renders them to HTML for display in a browser without additional server-side sanitization, attackers can execute arbitrary JavaScript in the context of the victim's session. This enables session hijacking through cookie theft, credential harvesting via keyloggers or form redirections, defacement of the application interface, or pivoting to further attacks against internal network resources if the rendered content is accessible from within a trusted zone. The vulnerability affects approximately ten distinct emission sites in the codebase, including paragraph and heading styles as well as table structures, meaning that almost any visual element containing styled text can serve as an injection vector. This broad surface area increases the likelihood of exploitation across various document types processed by vulnerable versions of the library.
To mitigate this risk, organizations using odf-kit must immediately upgrade to version 0.14.2 or later, where the developers have implemented a patch that ensures consistent escaping and validation for all rendered attributes, including inline CSS styles. For applications unable to update instantly due to dependency constraints, it is critical to implement robust server-side sanitization of any HTML output generated by odf-kit before serving it to clients. This should involve using established content security policies and HTML sanitizers such as DOMPurify or OWASP Java HTML Sanitizer to strip out dangerous tags and attributes after the conversion process. Additionally, developers should review their integration points for OpenDocument processing to ensure that no raw user-controlled data is passed directly into style properties without prior validation against a whitelist of allowed CSS values. Adhering to these practices aligns with security best practices outlined in OWASP guidelines and helps prevent exploitation via ATT&CK technique T1059, which covers command and script interpretation through browser-based vectors.