CVE-2026-119341 in Tesseract
Summary
by MITRE • 10/30/2026
Tesseract is an open source OCR engine. Prior to 5.5.4, ReadAdaptedClass in src/classify/adaptive.cpp raw-reads an ADAPT_CLASS_STRUCT from a pre-adapted-template .a file without neutralizing TempProtos and Config pointer fields before any destructor path. When the legacy engine is selected, classify_use_pre_adapted_templates is enabled, and an attacker can write the output-basename .a file, the success or rejection path can pass file-controlled pointers to ~ADAPT_CLASS_STRUCT and operator delete, causing memory corruption and denial of service. This issue is fixed in version 5.5.4.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The Tesseract Optical Character Recognition engine contains a critical vulnerability within its legacy template adaptation mechanism that allows for remote code execution or denial of service through crafted input files. Specifically, the flaw resides in the ReadAdaptedClass function located in src/classify/adaptive.cpp. This component is responsible for loading pre-adapted templates from .a archive files into memory to accelerate recognition processes when specific configuration flags are enabled. The vulnerability arises because the implementation fails to properly sanitize or neutralize pointer fields, specifically TempProtos and Config pointers, within the ADAPT_CLASS_STRUCT structure before these structures undergo destruction paths during error handling or normal cleanup operations.
When an attacker crafts a malicious .a file containing controlled values for these pointer fields, they can exploit this lack of validation under specific operational conditions. The vulnerability is triggered when the legacy engine mode is selected and the classify_use_pre_adapted_templates configuration option is enabled. Furthermore, the attack vector requires that the application allows writing to or processing output-basename files in a manner where the attacker controls the content of the .a template file being loaded. Under these circumstances, if the loading process encounters an error or completes successfully but triggers a destructor path for ADAPT_CLASS_STRUCT, the raw pointers stored within the structure are passed directly to memory deallocation functions such as operator delete without any validation checks.
This improper handling leads to severe memory corruption because the application attempts to free memory addresses that were not allocated by the current process heap or contain invalid data provided by the attacker. The immediate operational impact is a denial of service, characterized by application crashes and instability due to segmentation faults or access violations. However, given that arbitrary pointers are being passed to deallocation routines, this vulnerability also presents a significant risk for remote code execution if an attacker can control memory layout sufficiently to redirect execution flow through heap exploitation techniques. This aligns with CWE-416, Use After Free, and CWE-94, Improper Control of Generation of Code (Code Injection), as the manipulation of pointers allows potential injection of malicious logic into the application's runtime environment.
From a threat intelligence perspective, this vulnerability maps to MITRE ATT&CK technique T1055, Process Injection, specifically through memory corruption and pointer manipulation methods that allow an attacker to hijack control flow within a legitimate process. The exploitation relies on the interaction between file input validation failures and unsafe memory management practices inherent in legacy C++ code paths. To mitigate this risk, organizations must ensure that all instances of Tesseract are upgraded to version 5.5.4 or later where these pointer fields are properly neutralized before any destructor is invoked. Additionally, administrators should disable the use of pre-adapted templates if they are not strictly necessary for their specific OCR workloads, thereby removing the attack surface associated with loading external .a template files entirely. Input validation mechanisms should also be reinforced to ensure that only trusted and verified template sources are processed by the engine.