CVE-2026-88048 in Tesseract
Summary
by MITRE • 09/10/2026
Tesseract is an open source OCR engine. In version 5.5.3 and earlier, FullyConnected::DeSerialize in src/lstm/fullyconnected.cpp does not validate the deserialized layer scalars ni_ and no_ against the weight-matrix dimensions. During FullyConnected::Forward, MatrixDotVector in src/lstm/weightmatrix.cpp writes w.dim1() results into temp_line, which is sized from no_, and reads w.dim2() minus one inputs from curr_input, which is sized from ni_. A crafted .traineddata NT_SOFTMAX layer can therefore use inconsistent dimensions to cause a heap out-of-bounds write and read on the default LSTM engine, resulting in heap corruption, a crash, information disclosure, or potentially controlled corruption. No fixed release is available as of this review.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Tesseract versions 5.5.3 and earlier resides within the core neural network processing logic, specifically affecting the FullyConnected layer implementation used for LSTM-based recognition tasks. This open-source optical character recognition engine relies on serialized model files to load pre-trained weights and biases into memory structures that facilitate forward propagation during image analysis. The critical flaw occurs in the deserialization process where input parameters defining the dimensions of neural network layers are accepted without rigorous validation against the actual data contained within the weight matrix. Specifically, the FullyConnected::DeSerialize function fails to verify that the serialized layer scalars ni_ and no_, which represent the number of inputs and outputs respectively, align with the physical dimensions of the associated weight matrix w.dim1() and w.dim2(). This lack of boundary checking creates a fundamental inconsistency between the logical structure defined by the configuration data and the actual memory layout required for computation.
During the execution phase, when FullyConnected::Forward is invoked to process input vectors through this layer, the system utilizes MatrixDotVector from src/lstm/weightmatrix.cpp to perform matrix-vector multiplication operations. The implementation allocates a temporary buffer named temp_line based on the size of no_, which was derived directly from the unvalidated serialized data. Simultaneously, it attempts to read inputs from curr_input using w.dim2() minus one as the index limit. Because ni_ and no_ were not cross-referenced with the actual matrix dimensions during loading, a crafted .traineddata file containing an NT_SOFTMAX layer can specify inconsistent dimension values. This discrepancy allows for scenarios where the allocated buffer size does not match the amount of data being read or written, leading to heap out-of-bounds access conditions.
The operational impact of this memory safety violation is severe and multifaceted. The immediate consequence is heap corruption due to writes exceeding the boundaries of the allocated temp_line buffer or reads accessing memory outside the curr_input array. Such memory violations typically result in application crashes, causing a denial of service for any system relying on Tesseract for text extraction from images or documents. However, beyond simple instability, these out-of-bounds operations open pathways for more sophisticated attacks. An attacker could potentially leverage this flaw to achieve arbitrary code execution by carefully crafting the input data to overwrite adjacent memory structures with controlled values. Alternatively, reading outside buffer boundaries may lead to information disclosure, allowing sensitive data from other parts of the process heap to be leaked into the output stream or logged variables.
From a classification perspective, this vulnerability aligns closely with CWE-120 Buffer Copy without Checking Size of Input and CWE-787 Out-of-bounds Write, as the core issue is the failure to validate input sizes before performing memory operations that depend on those sizes. In terms of adversary tactics, this flaw facilitates exploitation techniques categorized under ATT&CK Tactic TA0004 Privilege Escalation or TA0005 Defense Evasion if leveraged for code execution, and specifically relates to technique T1203 Exploitation for Credential Access if used for information disclosure. The vulnerability highlights the risks associated with trusting serialized model files from untrusted sources without implementing strict schema validation and dimension consistency checks before memory allocation and computation.
Mitigation strategies must focus on both immediate defensive measures and long-term architectural improvements. Since no fixed release is available at the time of this review, users should avoid processing .traineddata files from unknown or unverified origins until an official patch is released. Implementing strict input validation within custom wrappers around Tesseract can help by verifying that layer dimensions match expected ranges before passing data to the engine. For developers integrating Tesseract into larger systems, isolating OCR processes in sandboxed environments with restricted memory access and resource limits can mitigate the impact of potential exploitation attempts. Ultimately, the resolution requires upstream patching where deserialization routines are updated to enforce rigorous consistency checks between declared layer dimensions and actual matrix sizes, ensuring that any mismatch results in a safe failure rather than undefined behavior.