Skip to content

← Public intelligence

crates.io package

ratex-parser

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 6.9crates.ioPublished

    ratex-parser has unbounded parser recursion that leads to stack overflow (process abort)

    CVE-2026-53531 · GHSA-4w5h-hx6r-28q7

    Affected
    • crates.io ratex-parser < 0.1.11
    Fixed in
    0.1.11· Vendor fix available
    Issue
    RaTeX’s recursive-descent parser recurses one (or more) native stack frame per nesting level at {, \left, \sqrt{, ^{, etc, with no maximum depth limit. A short, ~10 KB input of nested groups overflows the 8 MB main-thread stack and aborts the process. With panic = "abort" (Cargo.toml:48), and because a Rust stack overflow is always a fatal SIGABRT regardless of panic strategy this is an unrecoverable, whole-process denial of service reachable from a single untrusted LaTeX string. Details The mutual recursion has no depth guard (crates/ratex-parser/src/parser.rs): \left adds another recursive edge: handleleft → parseexpression (crates/ratex-parser/src/functions/leftright.rs:47). The only counters present are unrelated to depth: leftrightdepth (a \right-matching counter, parser.rs:24) and the macro expander’s maxexpand = 1000 (macroexpander.rs:64), which does not gate brace / \left recursion (those tokens never pass through expandonce). There is no recursionlimit/depth…

    Recommended action: Upgrade to 0.1.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. High, CVSS 8.7crates.ioPublished

    ratex-parser panics on \verb with a multibyte delimiter (UTF-8 byte-boundary slice)

    CVE-2026-53530 · GHSA-4hgp-59h5-gvrj

    Affected
    • crates.io ratex-parser < 0.1.11
    Fixed in
    0.1.11· Vendor fix available
    Issue
    The public parser entrypoint ratexparser::parse(&str) panics on the 9-byte input \verbéxé (i.e. \verb followed by the non-ASCII delimiter é). When handling a \verb command, the parser slices the verbatim argument with byte indices (arg[1..arg.len() - 1]); if the delimiter character is multibyte UTF-8, index 1 lands inside that character and Rust panics with “byte index 1 is not a char boundary”. Because RaTeX’s release profile sets panic = "abort" (Cargo.toml:48), the panic aborts the entire process — not just the current request/thread — making this a hard denial of service for any service that renders untrusted LaTeX. Details Affected code crates/ratex-parser/src/parser.rs, parsesymbolinner: For input \verbéxé: arg = "éxé", where é = U+00E9 (bytes C3 A9). arg.len() is the byte length (5), the < 2 guard passes, and arg[1..4] starts at byte index 1 — inside the first é (bytes 0..2) — so the slice panics. The lexer groups \verb<delim…<delim correctly with char semantics…

    Recommended action: Upgrade to 0.1.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →