CVE-2026-88047: 
Linux Red Hat vulnerability analysis and mitigation

CVE-2026-88047 is a stack-based buffer overflow vulnerability in Tesseract OCR engine's Classify::ReadNormProtos function, affecting all releases through version 5.5.3. An attacker who can supply a crafted .traineddata file can trigger up to 39 bytes of controlled stack corruption during TessBaseAPI::Init, leading to denial of service or potential control-flow hijacking. The vulnerability was reported by researcher Tristan Madani, published on September 10, 2026, and patched in version 5.5.4. It carries a CVSS v4.0 base score of 8.6 (High) (GitHub Advisory, Red Hat).

The root cause is a classic stack-based buffer overflow (CWE-121 / CWE-120) in src/classify/normmatch.cpp at line 193. The function Classify::ReadNormProtos reads each line of the NORMPROTO component of a .traineddata file using FGets(line, 100), then extracts the first whitespace-delimited token into a fixed 61-byte stack buffer (char unichar[2 * UNICHAR_LEN + 1]) via std::istream::operator>>(char*) — without ever setting a stream width limit. Because the line buffer allows up to 99 characters, a token exceeding 60 characters writes up to 39 attacker-controlled bytes past the end of unichar, clobbering adjacent stack state (saved frame pointer, return address, or local variables). The overflow occurs during TessBaseAPI::Init via the call chain: TessBaseAPI::Init → Classify::InitAdaptiveClassifier → ReadNormProtos. Notably, builds linked against Apple's libc++ in C++20 mode are incidentally protected due to a bounded array overload of operator>>, while libstdc++ builds (typical on Linux) remain vulnerable (GitHub Advisory, Fix Commit).

Successful exploitation causes deterministic stack corruption at model load time, with up to 39 attacker-controlled bytes written past the unichar buffer. On builds with stack canaries, this reliably crashes the process (denial of service); on builds without effective stack protection, the controlled stack write can enable control-flow hijacking and arbitrary code execution. The vulnerability affects confidentiality, integrity, and availability of the vulnerable system, and any application or service that passes untrusted .traineddata files to Tesseract's legacy OCR engine is at risk (GitHub Advisory).

No public proof-of-concept exploit or in-the-wild exploitation has been observed as of the disclosure date (Red Hat). The advisory includes a detailed proof-of-concept methodology (crafting a malicious eng.traineddata with a 99-character NORMPROTO token), and the vulnerability was reproduced with AddressSanitizer confirming a stack-buffer-overflow. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires the attacker to supply a crafted .traineddata file to a system running Tesseract with the legacy engine (--oem 0) (GitHub Advisory).

1. Craft a malicious .traineddata file: Create a eng.traineddata file containing a minimal valid unicharset, a minimal INTTEMP component (version 5, zero classes), an empty PFFMTABLE component, and a NORMPROTO component. In the NORMPROTO section, include a proto-line whose first token is exactly 99 'A' characters (the maximum a 100-byte line buffer can hold), followed by a newline.
2. Deliver the malicious file: Place the crafted eng.traineddata in a location where the target Tesseract installation will load it — for example, by replacing a legitimate model file, uploading it to a service that accepts user-supplied language models, or exploiting a path traversal in an application that uses Tesseract.
3. Trigger legacy engine initialization: Invoke Tesseract with the legacy OCR engine using the crafted model: tesseract test.png out -l eng --oem 0. This triggers TessBaseAPI::Init → Classify::InitAdaptiveClassifier → ReadNormProtos.
4. Overflow the stack buffer: During ReadNormProtos, FGets reads the 99-character line into the 100-byte line buffer. The subsequent stream >> unichar extraction (without a width limit on libstdc++ builds) writes 99 characters + NUL into the 61-byte unichar stack buffer, overflowing 39 bytes of adjacent stack state.
5. Achieve DoS or code execution: With stack canaries enabled, the process crashes (denial of service). Without effective stack protection, the attacker-controlled bytes overwrite the return address or saved frame pointer, enabling control-flow hijacking and potential arbitrary code execution (GitHub Advisory).

• File System: Presence of unexpected or modified .traineddata files (especially eng.traineddata) with anomalously large NORMPROTO token lines; files not matching known-good checksums of official Tesseract language model packages.
• Process: Tesseract process (tesseract) crashing unexpectedly or producing segmentation faults / stack smashing errors during initialization; crash dumps referencing Classify::ReadNormProtos or normmatch.cpp.
• Logs: Application logs showing Tesseract initialization failures with messages related to model loading; AddressSanitizer or stack canary violation messages (e.g., stack-buffer-overflow in __input_c_string) in debug or instrumented builds.
• Network: In web-facing applications using Tesseract, unusual uploads of .traineddata files or requests supplying custom model paths to OCR endpoints.

Upgrade Tesseract to version 5.5.4, which applies the fix by adding std::setw(2 * UNICHAR_LEN + 1) to bound the unichar extraction in ReadNormProtos (Fix Commit, GitHub Advisory). As a workaround prior to patching, restrict Tesseract to loading .traineddata files only from trusted, verified sources and validate model file integrity (e.g., via checksums) before use. Additionally, consider sandboxing OCR processing and enabling stack protection compiler flags (stack canaries, -fstack-protector-strong) to limit the impact of exploitation (Red Hat Bugzilla).

The vulnerability was reported by researcher Tristan Madani and the advisory was published by Tesseract maintainer Stefan Weil on GitHub. The fix commit credits OpenCode/qwen3.8-27b-thinking (Alibaba Cloud) as an assistant in the remediation. Red Hat tracked the issue via Bugzilla (Bug 2531550) and classified it as high severity. No significant broader media coverage or notable social media discussion beyond automated CVE tracking feeds has been observed (GitHub Advisory, Red Hat Bugzilla).