CVE-2026-119340 in Tesseract
Summary
by MITRE • 10/30/2026
Tesseract is an open source OCR engine. Prior to 5.5.4, GENERIC_2D_ARRAY::DeSerializeSize in src/ccstruct/matrix.h reads matrix dimensions as signed int32_t values and compares them only with UINT16_MAX, allowing negative values to reach ResizeNoInit. Negative dimensions or a 65535 by 65535 product can create inconsistent allocation state and later out-of-bounds accesses while loading a crafted traineddata file, causing denial of service. This issue is fixed in version 5.5.4.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified within the Tesseract open source optical character recognition engine stems from an insufficient validation mechanism during the deserialization process for matrix data structures. Specifically, the GENERIC_2D_ARRAY::DeSerializeSize function located in src/ccstruct/matrix.h is responsible for reading dimension parameters that define the size of two-dimensional arrays used internally by the OCR processing pipeline. In versions prior to 5.5.4, this function retrieves these dimensions as signed thirty-two-bit integers but performs a boundary check against an unsigned sixteen-bit maximum value, specifically UINT16_MAX. This logical flaw creates a critical discrepancy because it fails to account for negative integer values that result from two's complement representation when the input data is crafted maliciously. Consequently, negative dimension values bypass the upper bound check and are passed directly to subsequent memory allocation routines without proper sanitization or range validation appropriate for signed integers.
The operational impact of this flaw manifests as a denial of service condition triggered by loading a specially constructed traineddata file. When the system attempts to process these invalid dimensions, it proceeds to call ResizeNoInit with negative values or excessively large products such as sixty-five thousand five hundred and thirty-five multiplied by itself. This leads to an inconsistent allocation state where memory is either allocated incorrectly or not at all, depending on how the underlying allocator interprets the malformed size parameters. Subsequent operations that rely on these matrix structures attempt to access memory regions based on these invalid dimensions, resulting in out-of-bounds reads or writes. These illegal memory accesses disrupt normal program execution and can cause the application to crash immediately, thereby preventing legitimate users from utilizing the OCR capabilities of the software.
From a classification perspective, this vulnerability aligns with CWE-190, which describes integer overflow or wraparound issues that lead to incorrect behavior when arithmetic operations exceed expected bounds. Additionally, it relates closely to CWE-20 regarding improper input validation, as the system fails to correctly validate negative values against constraints intended for unsigned types. In terms of attack vectors and techniques, this flaw is exploitable via ATT&CK technique T1190, which involves exploiting public-facing applications in remote services or systems. An attacker can craft a malicious traineddata file that exploits this deserialization logic to trigger the crash remotely if the service processes untrusted input files without adequate sandboxing or validation layers.
Mitigation for this vulnerability requires upgrading to version 5.5.4 of Tesseract, where the developers have corrected the type handling and comparison logic within the DeSerializeSize function. For environments that cannot immediately upgrade, defensive coding practices should be implemented at any wrapper layer consuming these libraries. This includes enforcing strict input validation on all external data sources before they reach the OCR engine, ensuring that dimension parameters are explicitly checked for both positive values and reasonable upper bounds consistent with available system memory. Furthermore, implementing runtime protection mechanisms such as address space layout randomization and stack canaries may help mitigate the consequences of any remaining out-of-bounds accesses by preventing code execution exploits, although these measures do not prevent the denial of service condition itself. Regular security audits focusing on deserialization routines are recommended to identify similar logic errors in other components that handle binary data formats.