CVE-2026-88049 in Tesseract
Summary
by MITRE • 09/10/2026
Tesseract is an open source OCR engine. In version 5.5.3 and earlier, prior .traineddata hardening added bounds checks to NetworkIO::CopyTimeStepGeneral and NetworkIO::Randomize in src/lstm/networkio.cpp but left NetworkIO::WriteTimeStepPart and NetworkIO::AddTimeStepPart unchecked. In LSTM::Forward in src/lstm/lstm.cpp, source_ is sized from the independently deserialized na_ field while the WriteTimeStepPart count is ns_, which comes from the CI gate WeightMatrix dim1() value. A crafted NT_LSTM layer can make ns_ much larger than na_, causing a heap out-of-bounds write during the first recognition step on the default LSTM engine and resulting in heap corruption, a crash, 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 within Tesseract versions 5.5.3 and earlier represents a critical memory safety flaw rooted in inconsistent input validation during the processing of Long Short-Term Memory neural network layers. Tesseract, widely recognized as an open-source optical character recognition engine, relies on complex internal structures to interpret image data into text. The specific defect resides within the LSTM module's handling of serialized weight matrices and time-step data. While previous security hardening efforts correctly implemented bounds checking for certain functions such as NetworkIO::CopyTimeStepGeneral and NetworkIO::Randomize in src/lstm/networkio.cpp, a significant oversight left other critical paths unchecked. Specifically, the functions NetworkIO::WriteTimeStepPart and NetworkIO::AddTimeStepPart were not subjected to equivalent validation mechanisms, creating an asymmetry in security controls that attackers can exploit through carefully crafted input files.
The technical mechanism of this vulnerability involves a discrepancy between two distinct data sources used during the LSTM forward pass operation defined in src/lstm/lstm.cpp. During the initialization phase, the source buffer size is determined by deserializing the na_ field from the model file. However, when writing time-step parts to this buffer, the system utilizes ns_, which is derived directly from the dim1() value of a CI gate WeightMatrix contained within the same serialized data structure. Because these two values are not cross-validated against each other prior to memory allocation and write operations, an attacker can construct a malicious NT_LSTM layer where the declared dimension for writing (ns_) significantly exceeds the allocated buffer size based on na_. This mismatch leads directly to a heap out-of-bounds write condition when the first recognition step is executed using the default LSTM engine.
The operational impact of this vulnerability is severe, primarily manifesting as heap corruption that can destabilize the application environment. In many scenarios, the immediate result will be an application crash due to memory access violations triggered by writing beyond allocated boundaries. However, given the nature of heap-based buffer overflows in C++ applications like Tesseract, the consequences extend far beyond simple denial of service. An attacker with the ability to supply a crafted input file can potentially achieve controlled corruption of adjacent heap metadata or data structures. This level of control opens pathways for arbitrary code execution, allowing an adversary to inject and run malicious payloads within the context of the process running Tesseract. The severity is further amplified by the fact that no fixed release was available at the time of review, leaving users exposed until a patch is officially released.
From a classification perspective, this vulnerability aligns with CWE-122, which denotes heap-based buffer overflow, and specifically relates to improper input validation leading to memory corruption. In terms of offensive security frameworks such as MITRE ATT&CK, this flaw facilitates initial exploitation techniques that rely on crafting malicious files to trigger remote code execution or privilege escalation depending on the deployment context. The lack of bounds checking in specific serialization paths highlights a common pitfall in software development where partial remediation efforts may inadvertently create new attack surfaces if not applied comprehensively across all related functions.
Mitigation strategies for this vulnerability must focus on both immediate defensive measures and long-term architectural improvements. Since no official patch was available at the time of discovery, organizations relying on Tesseract should consider implementing input sanitization layers that validate serialized model files before they are processed by the LSTM engine. This includes verifying that dimension parameters in weight matrices do not exceed expected bounds relative to other declared sizes within the same structure. Additionally, enabling compiler-based security features such as stack canaries and heap protection mechanisms like AddressSanitizer during development or deployment testing can help detect these memory violations earlier. For production environments where upgrading is not immediately feasible, restricting the execution of Tesseract to unprivileged users with limited file system access can reduce the potential impact of a successful exploitation attempt. Ultimately, developers must ensure that all code paths involved in deserializing and processing neural network weights undergo rigorous bounds checking to prevent similar discrepancies from arising in future versions.