CVE-2026-119338 in Tesseract
Summary
by MITRE • 10/30/2026
Tesseract is an open source OCR engine. From 5.4.0 until 5.5.4, AppendLinePolygon in src/api/pagerenderer.cpp destroys the caller-owned right-to-left Pta accumulator while receiving it by value, leaving line_top_rtl_pts and line_bottom_rtl_pts dangling. On an upright Hebrew or Arabic page at the default PAGE XML level, POLYGONFLAG with a false skewed_flag enters the vulnerable calls, while LEVELFLAG greater than zero provides an alternative gate. The calls repeatedly read and free the stale object, causing a double free and use after free and allowing corrupted coordinates to reach RecalcPolygonline. This issue is fixed in version 5.5.4.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified within Tesseract versions ranging from 5.4.0 through 5.5.4 represents a critical memory management flaw located specifically within the AppendLinePolygon function found in src/api/pagerenderer.cpp. This open-source optical character recognition engine processes document layouts and text lines, often dealing with complex scripts such as Hebrew or Arabic that utilize right-to-left writing directions. The core technical defect arises from an improper handling of ownership semantics for a PointArray accumulator used to store polygon coordinates. When the function receives this accumulator by value rather than by reference or pointer with explicit transfer-of-ownership rules, it creates a scenario where multiple instances of the same object exist in memory simultaneously without proper synchronization of their lifecycle states.
The operational trigger for this vulnerability occurs under specific rendering conditions involving upright pages containing Hebrew or Arabic text at the default PAGE XML level. The code path is entered when POLYGONFLAG indicates that skewed_flag is false, while a LEVELFLAG greater than zero provides an alternative gate condition. Under these circumstances, the function proceeds to process line coordinates using right-to-left accumulators designated as line_top_rtl_pts and line_bottom_rtl_pts. Because the accumulator is passed by value, the original caller retains ownership of the underlying memory block, yet the local copy within AppendLinePolygon also attempts to manage it. This discrepancy leads directly to a double free vulnerability where the same memory address is deallocated multiple times during execution.
The consequences of this flaw extend beyond simple memory corruption due to the subsequent use-after-free condition that follows the initial double free event. After the stale object is freed, the code continues to read from and write to the now-invalid memory location. This allows corrupted coordinate data to propagate further into the processing pipeline, eventually reaching the RecalcPolygonline function. The injection of malformed geometric data can lead to unpredictable application behavior, including crashes that may facilitate denial-of-service attacks against systems relying on Tesseract for document analysis. In more severe scenarios involving carefully crafted inputs, this memory corruption could potentially be leveraged to execute arbitrary code by overwriting adjacent heap metadata or control flow pointers.
From a classification perspective, this vulnerability aligns with CWE-415 Double Free and CWE-416 Use After Free as defined in the Common Weakness Enumeration standard. These categories highlight failures in managing dynamic memory allocation and deallocation lifecycles. In terms of adversary tactics, exploitation attempts would likely fall under ATT&CK technique T1203 Exploitation for Defense Evasion or potentially T1190 Exploit Public-Facing Application if the vulnerability is triggered via a network-accessible service wrapping Tesseract. The lack of strict ownership transfer mechanisms in C++ APIs often leads to such subtle but dangerous memory safety issues, particularly when value semantics are misapplied to resources that require exclusive access during their lifetime.
Mitigation strategies for this issue primarily involve upgrading to version 5.5.4 or later where the developer has corrected the parameter passing mechanism and ensured proper ownership transfer. For organizations unable to immediately patch, implementing input validation to restrict processing of complex right-to-left scripts at specific PAGE XML levels may reduce exposure, though this is not a robust defense given the complexity of OCR workloads. Long-term remediation should include adopting static analysis tools capable of detecting memory management errors in C++ codebases and enforcing coding standards that mandate explicit move semantics or smart pointers for resources with complex lifecycles to prevent similar ownership ambiguities in future development cycles.