CVE-2026-33046: LaTeX Injection Leading to Local File Disclosure and Remote Code Execution in Indico

Indico relies on the TeXLive environment and the XeLaTeX engine to generate PDF documents such as event badges, posters, and books of abstracts. The application accepts user-supplied text for these documents and applies a Python-based sanitization routine to neutralize dangerous LaTeX commands. This sanitization process aims to prevent the execution of commands like \input or \write18 that interact with the underlying host filesystem or system shell.

CVE-2026-33046 represents a failure in this sanitization mechanism due to a mismatch between the application's regular expression filters and the complex parsing logic of the XeLaTeX engine. Attackers successfully smuggle restricted commands through the sanitizer using alternative encoding formats native to TeX. The vulnerability affects all Indico versions prior to 3.3.12 where server-side LaTeX rendering is enabled.

Exploitation results in Local File Disclosure (LFD), granting an attacker read access to sensitive server files. This includes the Indico configuration file containing database credentials and application secret keys. If the underlying TeX environment operates with the shell-escape feature enabled, the vulnerability escalates to unauthenticated Remote Code Execution (RCE) via system command execution.

The root cause of this vulnerability lies in the improper neutralization of TeX caret notation (CWE-74). TeX engines natively support ASCII and Unicode character representation using sequences of carets followed by hexadecimal digits. For example, the sequence ^^5c is parsed by the engine as a literal backslash (\), while extended XeLaTeX implementations also support four-caret (^^^^) and six-caret representations for broader Unicode code points.

Indico's original sanitization logic primarily searched for literal backslash characters to identify the start of a dangerous LaTeX command block. By substituting literal backslashes with their caret notation equivalents, an attacker effectively hides restricted commands from the Python regex engine. The XeLaTeX compiler subsequently decodes the caret sequences during the rendering phase and executes the smuggled command as intended by the attacker.

Compounding this issue is the recursive nature of caret resolution within the TeX parsing pipeline. The engine resolves notation iteratively, meaning sequences like ^^5e^5c evaluate to ^5c in the first pass, and then to \ in the second pass. The application's sanitizer did not account for recursive decoding, rendering static pattern matching strictly ineffective against layered obfuscation.

Additional logic errors further weakened the security boundary. A typographical error in the regular expression responsible for identifying math-mode blocks (\$\$(^\$)\$\$ instead of \$\$[^\$]+\$\$) caused the sanitizer to entirely skip validation for specific segments of user input. Furthermore, the global whitelisting of the \begin{...} command allowed attackers to instantiate unsafe LaTeX environments without restriction.

The remediation for CVE-2026-33046 required a fundamental redesign of the sanitization pipeline to mirror the state machine of the XeLaTeX parser. Initial patch attempts focused on addressing the math-mode typo and adding basic regex rules for ^^5c. Subsequent commits expanded this coverage to handle multiple carets, leading zeros, and recursive resolution mechanisms.

Commit 0adb70f0ed66e129361d447868f5f3eb90dc5e96 introduced a dedicated function, _resolve_latex_carets, designed to recursively decode all hex sequences before the primary sanitization logic executes. This ensures the sanitizer evaluates the payload exactly as the TeX engine will ultimately interpret it. Commit 5f24d23ce9c4b0e4b68b3d0b58987a948fc57c8a further hardened this parser with strict Unicode range validation.

The implementation utilizes a while loop to repeatedly search for and resolve caret sequences until no further patterns match. The following snippet demonstrates the core logic of the recursive resolution function introduced in the patch:

def _resolve_latex_carets(text):
    done = False
    while not done:
        done = True
        while m := re.search(r'(\^{2,})(?=[a-f0-9])', text):
            num = len(m.group(1))
            # Logic to resolve ^^^^ or ^^^^^^ based on hex string length
            # ...
            ccode = int(text[end : end + num], 16)
            char = chr(ccode) if ccode and ccode <= 0x10ffff else ''
            text = text[:start] + char + text[end + num :]
            done = False
    return text

By fully expanding the text before enforcing the blacklist, the application successfully normalizes obfuscated inputs. The patch also modifies the \begin command handling, transitioning from a global whitelist to a strict allowlist of specific, safe environments.

Exploitation requires an attacker to possess permissions to submit text to a field that is subsequently rendered via Indico's PDF engine. Common attack vectors include the submission of event abstracts, speaker biographies, or custom badge configurations. The application must also have server-side LaTeX rendering enabled via the XELATEX_PATH configuration directive.

The attacker begins by identifying a suitable injection point and crafting a payload utilizing caret notation. To achieve Local File Disclosure (LFD), the attacker uses the smuggled backslash to invoke the \input command. A typical payload takes the form of ^^5cinput{/opt/indico/etc/indico.conf}. Extended zero-padding, such as ^^^^005cinput, evades rudimentary regex updates deployed in early, incomplete patches.

Upon submission, the attacker triggers the PDF generation process by accessing the relevant download endpoint, such as the "Download Book of Abstracts" feature. The Indico backend passes the unsanitized payload directly to the XeLaTeX compiler. The compiler resolves the caret notation, executes the \input command, and embeds the raw text contents of the target file directly into the output document.

The attacker downloads the generated PDF and extracts the embedded data. In specific edge cases where the TeXLive environment is configured with the shell-escape parameter enabled, attackers pivot to arbitrary command execution. A payload such as ^^5cwrite18{id > /tmp/pwned} directs the system shell to execute the id command and write the resulting output to a world-readable directory.

The primary impact of CVE-2026-33046 is the total loss of confidentiality for files readable by the Indico application user. Attackers leverage the LFD vector to extract sensitive configuration files, including the primary indico.conf. This configuration file explicitly contains database connection strings, application secret keys, and SMTP credentials.

Access to the database credentials permits the attacker to establish a direct connection to the backend database, assuming network routing conditions permit. This facilitates the mass extraction of user data, password hashes, and proprietary event information. Compromise of the application secret key enables the forging of arbitrary session tokens, leading directly to full administrative takeover of the Indico instance.

If the shell-escape feature is enabled within the system's TeX environment, the vulnerability results in Remote Code Execution (RCE). The attacker gains the ability to execute arbitrary system commands within the context of the user running the XeLaTeX process. This enables lateral movement within the network, persistent backdoor installation, and complete server compromise.

The CVSS v4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) reflects the high severity of the flaw. The vulnerability requires low privileges to exploit and requires no user interaction, but necessitates the specific condition of server-side LaTeX compilation being actively utilized and configured.

The primary remediation strategy is to upgrade the Indico application to version 3.3.12 immediately. This release contains the comprehensive _resolve_latex_carets parsing function and the corrected math-mode regular expressions. Administrators must verify that the deployment successfully pulls the updated sanitization routines and restarts the necessary services.

Beyond patching the application code, Indico version 3.3.12 introduces structural mitigation via containerization. Administrators are strongly advised to enable the containerized LaTeX renderer utilizing Podman. By modifying indico.conf to set XELATEX_PATH = 'podman', the xelatex process is isolated within a tightly restricted sandbox, entirely decoupling it from the host filesystem and blocking LFD attacks at the system level.

For environments where an immediate upgrade is impossible, administrators must implement a temporary workaround by disabling server-side LaTeX rendering entirely. This is achieved by removing or commenting out the XELATEX_PATH directive in indico.conf. Both the indico-uwsgi and indico-celery services must be restarted for this configuration change to take effect.

Security teams should monitor application logs for indicators of compromise. Searching user submission logs for patterns containing multiple carets followed by hexadecimal characters (e.g., \^{2,}[0-9a-fA-F]{2,}) identifies active exploitation attempts. Web Application Firewalls (WAF) must be configured with equivalent regular expressions to block malicious payloads at the network perimeter before they reach the application layer.