Description

Kroki creates diagrams from textual descriptions. Prior to 0.31.2, the TikZ backend's tikz/tikz2svg guard used when KROKI_SAFE_MODE is enabled blocks only \verbatiminput while allowing native TeX file-read primitives including \openin, \read, \input, and \include. TeX Live's permissive openin_any setting remains active, so an unauthenticated actor can submit crafted LaTeX to POST /tikz/svg or the generic diagram API and cause the renderer to read any file accessible to the Kroki container user. The file contents are rendered into the returned SVG, which may disclose mounted secrets, configuration data, credentials, private keys, or process environment data. The -no-shell-escape option prevents shell execution but does not restrict these native file operations. This issue is fixed in version 0.31.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-11-06T18:17:37.110Z",
  "pubdate": "2026-11-06T18:17:37.110Z",
  "executiveSummary": "Kroki versions prior to 0.31.2 contain a critical Arbitrary File Read vulnerability within the TikZ diagram backend. This security flaw stems from an insufficient input validation mechanism when KROKI_SAFE_MODE is active. The vulnerability allows unauthenticated remote attackers to bypass existing security filters and leverage native TeX file-read primitives, such as \\input and \\openin, to access sensitive files on the host filesystem.\nThe impact of this vulnerability is significant, as it permits the extraction of sensitive data including mounted secrets, configuration files, credentials, private keys, and environment variables. Because the TikZ renderer processes these files and embeds their contents into the resulting SVG output, the attacker can receive the sensitive file content directly in the API response. Exploitation does not require prior authentication or elevated privileges, making it a high-risk vector for containerized environments. This issue is resolved in version 0.31.2, which introduces improved security boundaries for the TikZ rendering process.",
  "technicalDetails": "The root cause of the vulnerability lies in the inadequate implementation of the security guard for the TikZ backend. While Kroki utilizes the -no-shell-escape option to prevent arbitrary command execution, this security control is insufficient to prevent TeX engine-level file I/O operations. The guard used to enforce KROKI_SAFE_MODE only explicitly blocks the \\verbatiminput command, erroneously assuming this sufficiently mitigates file inclusion risks.\nThe TeX Live environment remains configured with a permissive openin_any setting, which allows the engine to interact with the underlying filesystem. Because the guard fails to blacklist primitive file-read operations—specifically \\openin, \\read, \\input, and \\include—the TeX engine retains full capability to open and parse files accessible to the user account running the Kroki container process.\nThe attack flow follows a predictable pattern: An unauthenticated attacker sends a specially crafted LaTeX payload to the POST /tikz/svg endpoint or the general Kroki diagram API. This payload leverages TeX primitives to reference target file paths on the server. For example, a malicious request might include a snippet such as \\input{/etc/passwd} or a more complex sequence involving \\openin and \\read to capture the contents of sensitive configuration files or environment variable dumps. Upon processing the request, the TikZ renderer executes these primitives, reads the targeted file from the disk, and renders the extracted text as a graphical element within the generated SVG output. The server then returns this SVG to the attacker, effectively functioning as an exfiltration oracle.\nThis vulnerability is particularly severe because the -no-shell-escape flag provides a false sense of security; while it prevents the attacker from spawning shells or executing arbitrary system binaries, it does not restrict the TeX engine's internal ability to read the local filesystem. As a result, the confidentiality of the containerized environment is entirely compromised, allowing an attacker to map the internal filesystem and exfiltrate sensitive secrets or credentials stored within the Kroki container or mounted volumes. This bypass necessitates a more robust sanitization approach that explicitly restricts file access at the TeX engine level or via container-side security policies."
}