CVE-2026-88052

What it actually does

Tesseract 5.5.3 and earlier contain an unchecked-index heap write in UNICHARSET loading. load_via_fgets trusts a declared unichar count as a loop bound while unichar_insert_backwards_compatible may not grow the unichars vector for empty, duplicate, or already-encodable entries. The resulting out-of-bounds writes to UNICHAR_PROPERTIES during LSTM and legacy engine initialization can crash the process or corrupt adjacent heap state in the OCR worker.

Why it matters to the business

Any product that runs Tesseract on files, language packs, or traineddata from users, vendors, or the public internet can suffer OCR outages or, in worse cases, compromise of the process that performs recognition. Impact is local and needs the victim to process a crafted file, but public exploit code is already available and no official patched release exists more than three weeks after disclosure, so exposure remains open-ended for document pipelines, scanners, and RPA/OCR services.

How an attack unfolds

An attacker supplies a malicious unicharset or traineddata artifact rather than attacking Tesseract over the network. When the victim (or an automated pipeline) loads that data, initialization walks past the end of the unichars vector and corrupts the heap. The realistic outcomes are a reliable crash of the OCR process or, with a carefully shaped file, further memory corruption in the same process. Named ransomware or APT use is not reported; abuse is most likely via poisoned language data, a malicious document workflow, or a local file the user is induced to recognize.

How to fix it

No fixed Tesseract release is published. Stop loading unicharset and traineddata files from untrusted sources; pin known-good language data; run OCR in a tightly sandboxed, least-privilege process (container, seccomp, no extra mounts or credentials); and track upstream tesseract-ocr for a patch to UNICHARSET::load_via_fgets / unichar_insert_backwards_compatible. Do not treat rebuilding 5.5.3 as a fix. If you vendor Tesseract, add bounds checks so id is never used beyond unichars.size() and reject declared counts that do not match inserted entries.

How to confirm the fix worked

Inventory every binary, container, and language-pack path that ships tesseract or libtesseract and confirm whether the engine is 5.5.3 or earlier. Verify OCR workers only load signed or internally curated traineddata, and that untrusted uploads never reach unicharset load. After sandbox or input-policy changes, process a known-good language pack and confirm recognition still works; do not validate by running public crash files against production. Re-check when an official release that bounds the unichar index ships.

Typical attack path

1. Obtain or generate a unicharset/traineddata file that desynchronizes the declared character count from the actual vector length.
2. Deliver the file through a channel the victim already trusts for OCR input (shared language packs, document ingest, plugin, or local open).
3. Wait for Tesseract 5.5.3 or earlier to load the file during LSTM or legacy engine setup.
4. Trigger heap corruption that aborts recognition or undermines the OCR process.
5. If the process runs with broader rights than needed, use that foothold only to affect the host or adjacent documents—not as a remote wormable step.

How to detect it

This is a local initialization bug, not a network service flaw, so look for crashes and unexpected language data rather than C2. Review host and container logs for tesseract/libtesseract aborts, segfaults, or fatal heap errors around OCR jobs; inspect core dumps or crashpad reports whose stacks mention unicharset load or engine init. Compare traineddata and unicharset files on disk against known-good hashes and alert on new language packs appearing outside your curated directory. There are no named threat actors or KEV ransomware campaigns to key on; a crash while loading newly introduced language data is the primary retrospective signal.

What your security team should do

• Treat this as unpatched High (CVSS 7.8) with public exploit code: isolate Tesseract immediately rather than waiting for a vendor tag.
• Block or quarantine untrusted .traineddata, unicharset, and third-party language packs at ingest.
• Sandbox OCR (separate user, no secrets, no writable app volumes) so a crash or heap smash cannot reach the rest of the host.
• Find all downstream uses of tesseract-ocr and freeze language-data updates until a patched engine is available.
• Watch upstream for a release that rejects oversize declared unichar counts; upgrade as soon as one exists.
• Hunt for recent tesseract crashes and unexpected language-data drops; public KEV/ransomware use is not indicated, but exploit maturity is not theoretical.