CVE-2026-88053 in Tesseract
Summary
by MITRE • 09/10/2026
Tesseract is an open source OCR engine. In version 5.5.3 and earlier, Classify::ReadIntTemplates in src/classify/intproto.cpp reads NumClassPruners, NumClasses, and NumProtoSets from the TESSDATA_INTTEMP component of a crafted .traineddata file and uses those values as loop bounds without validating them against MAX_NUM_CLASS_PRUNERS, MAX_NUM_CLASSES, and MAX_NUM_PROTO_SETS. The loops store heap pointers into fixed-capacity ClassPruners and ProtoSets arrays in INT_TEMPLATES_STRUCT and INT_CLASS_STRUCT, so an oversized count causes heap out-of-bounds pointer writes during legacy-classifier initialization before OCR begins, resulting in heap corruption, a crash, or potentially controlled corruption. No fixed release is available as of this review.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Tesseract versions 5.5.3 and earlier represents a critical memory safety flaw within the engine's legacy classifier initialization process. Specifically, the issue resides in the Classify::ReadIntTemplates function located in src/classify/intproto.cpp. This component is responsible for parsing trained data files that contain pre-trained character recognition models used by the optical character recognition system. The core technical deficiency involves a failure to perform bounds checking on integer values extracted from untrusted input sources, specifically the TESSDATA_INTTEMP section of crafted .traineddata files. When processing these files, the function retrieves three specific parameters: NumClassPruners, NumClasses, and NumProtoSets. These integers are subsequently utilized directly as loop bounds for memory allocation or iteration operations without any validation against their respective maximum allowable limits defined by MAX_NUM_CLASS_PRUNERS, MAX_NUM_CLASSES, and MAX_NUM_PROTO_SETS.
This lack of input validation leads to a heap out-of-bounds write condition during the initialization phase of the legacy classifier. The code attempts to store pointers into fixed-capacity arrays named ClassPruners within INT_TEMPLATES_STRUCT and ProtoSets within INT_CLASS_STRUCT. Because the loop bounds are derived from attacker-controlled data rather than validated constants, an oversized count causes the program to write heap pointers beyond the allocated boundaries of these static or stack-allocated structures. This results in immediate memory corruption on the heap. The operational impact is severe, as such corruption typically leads to application crashes due to segmentation faults or undefined behavior. However, given the nature of heap-based buffer overflows, a sophisticated attacker could potentially manipulate this out-of-bounds write to achieve controlled memory corruption, which may facilitate arbitrary code execution depending on the specific runtime environment and available exploitation techniques.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input Classic, as it involves writing data beyond the bounds of a buffer due to insufficient size validation. It also relates closely to CWE-787 Out-of-bounds Write, which describes the act of writing to a memory location outside of the intended boundary. In terms of adversary tactics and techniques, this flaw could be leveraged within an ATT&CK framework context under T1059 Command and Scripting Interpreter or potentially as part of initial access vectors if the OCR engine is integrated into a service that processes untrusted documents, allowing for remote code execution through crafted document uploads. The absence of a fixed release at the time of review highlights the critical need for immediate mitigation strategies by organizations relying on this open-source software.
To mitigate this risk in environments where Tesseract is deployed, several defensive measures should be implemented immediately since no official patch exists yet. First and foremost, input validation must be enforced at the application layer before any data reaches the OCR engine. Applications processing .traineddata files or other model inputs should verify that all integer parameters fall within expected safe ranges consistent with known maximums for NumClassPruners, NumClasses, and NumProtoSets. Additionally, deploying runtime protection mechanisms such as Address Sanitizers during testing phases can help detect these out-of-bounds writes early in the development lifecycle. For production systems, consider implementing strict file format validation using allowlists to ensure that only trusted, verified model files are loaded into memory. Furthermore, isolating the OCR processing tasks within sandboxed environments or containers with restricted memory access limits can reduce the blast radius of a potential exploitation attempt, preventing heap corruption from affecting critical system components or leading to full system compromise.