CVE-2026-88053

What it actually does

Tesseract 5.5.3 and earlier read NumClassPruners, NumClasses, and NumProtoSets from the TESSDATA_INTTEMP component of a .traineddata file and use those values as loop bounds without checking MAX_NUM_CLASS_PRUNERS, MAX_NUM_CLASSES, or MAX_NUM_PROTO_SETS. The loops write heap pointers into fixed-capacity ClassPruners and ProtoSets arrays in INT_TEMPLATES_STRUCT and INT_CLASS_STRUCT, so oversized counts cause heap out-of-bounds pointer writes during legacy-classifier initialization, producing heap corruption, a crash, or potentially attacker-influenced corruption before OCR runs.

Why it matters to the business

Any product or pipeline that runs Tesseract for document intake, scanning, or search can be crashed or have the OCR process memory corrupted if an untrusted language-model file is loaded. There is no vendor fix as of this review, public exploit material is reported available, and the issue has been public for about 27 days, so OCR-dependent operations face unpatched availability and integrity risk until models are locked down or an upstream patch ships.

How an attack unfolds

An attacker supplies a crafted .traineddata file whose TESSDATA_INTTEMP section advertises class-pruner, class, or proto-set counts larger than the engine’s fixed array capacities. The file is loaded from a tessdata directory, TESSDATA_PREFIX, --tessdata-dir, or an application-bundled model path that the victim process trusts. On classifier init, Classify::ReadIntTemplates uses the unvalidated counts as loop bounds and writes pointers past ClassPruners and ProtoSets, corrupting the heap. The process then crashes or continues with a corrupted heap, which can undermine integrity of the OCR worker. This is a local file-load issue: the attacker must get the malicious model onto a path Tesseract will open; they do not need privileges or extra UI clicks once that path is used.

How to fix it

No fixed Tesseract release is available. Until a patched build exists: load only known-good .traineddata files from a tightly controlled tessdata directory; block or ignore user-supplied and network-retrieved models; set TESSDATA_PREFIX and --tessdata-dir to a read-only, root-owned path and deny write access to unprivileged users and application roles; run tesseract/libtesseract in a sandbox (seccomp, containers, low-privilege service account) with no extra filesystem or network rights; pin and integrity-check shipped models (hashes/signatures); prefer not initializing the legacy classifier if your build/API allows using only LSTM/modern models; inventory all downstream packages that vendor tesseract-ocr 5.5.3 or earlier and plan a fast upgrade when a fix is published.

How to confirm the fix worked

Inventory hosts and images for tesseract or libtesseract 5.5.3 and earlier (package managers, container SBOMs, language bindings). Confirm tessdata paths and TESSDATA_PREFIX point only at signed, hashed, read-only model sets and that untrusted .traineddata cannot be introduced. After applying a future vendor patch, verify the installed version is newer than 5.5.3 and that ReadIntTemplates rejects oversized NumClassPruners/NumClasses/NumProtoSets (or that the legacy path is removed). Regression-test OCR startup with your production models only; do not use untrusted samples to ‘prove’ the bug.

Typical attack path

1. Obtain write or supply influence over a .traineddata file that the target Tesseract process will load (tessdata directory, TESSDATA_PREFIX, CLI/API model path, or bundled models).
2. Craft TESSDATA_INTTEMP counts (NumClassPruners, NumClasses, NumProtoSets) larger than the engine’s fixed array limits.
3. Trigger legacy-classifier initialization (normal OCR startup or first recognition using that model).
4. Heap out-of-bounds pointer writes corrupt ClassPruners/ProtoSets-related structures.
5. Process crashes or continues with corrupted heap, disrupting OCR or enabling further memory-safety impact in that process.

How to detect it

This is a local model-load memory-corruption bug, so look for evidence that Tesseract initialized the legacy classifier from a non-standard .traineddata rather than for a network signature. Review process crash dumps and stderr from tesseract/libtesseract around Classify::ReadIntTemplates / src/classify/intproto.cpp; unexpected SIGSEGV/SIGABRT during OCR startup (before recognition output) is the primary runtime signal. Compare on-disk .traineddata under tessdata, TESSDATA_PREFIX, and --tessdata-dir against known-good hashes from the project or your golden images; flag new, oversized, or recently replaced models. Audit command lines and library callers for custom --tessdata-dir, TESSDATA_PREFIX, or API SetDatapath usage. Container/host file-integrity and package logs showing tesseract 5.5.3 or earlier plus a modified traineddata file are the strongest pre-exploit exposure indicators; core files mentioning INT_TEMPLATES_STRUCT or ClassPruners after a model change suggest the bug was triggered. No named threat actors are associated in the supplied data.

• Classify::ReadIntTemplates
• src/classify/intproto.cpp
• TESSDATA_INTTEMP
• INT_TEMPLATES_STRUCT
• ClassPruners
• ProtoSets
• NumClassPruners
• NumProtoSets
• TESSDATA_PREFIX
• --tessdata-dir
• tesseract
• libtesseract
• *.traineddata

What your security team should do

• Treat untrusted .traineddata as untrusted code: block user/upload/network model load paths immediately.
• Lock tessdata directories and TESSDATA_PREFIX to read-only known-good files and monitor for unexpected writes or new .traineddata.
• Sandbox every Tesseract worker and drop privileges so a crash or heap corruption cannot reach adjacent services.
• Hunt for tesseract <= 5.5.3 in images, desktop OCR tools, and language bindings; track upstream for the first fixed release and patch on day zero.
• Because exploit material is reported available and no patch exists, prioritize OCR-facing internet or multi-tenant document pipelines over air-gapped, model-pinned deployments.