CVE-2026-88049

What it actually does

Tesseract 5.5.3 and earlier contain a heap out-of-bounds write in the default LSTM engine. Hardening added bounds checks to NetworkIO::CopyTimeStepGeneral and NetworkIO::Randomize but left NetworkIO::WriteTimeStepPart and NetworkIO::AddTimeStepPart unchecked. In LSTM::Forward, the source buffer is sized from the deserialized na_ field while the write count uses ns_ from the WeightMatrix dim1() CI gate. A crafted NT_LSTM layer can set ns_ much larger than na_, so the first recognition step writes past the heap buffer, causing heap corruption, a crash, or potentially attacker-influenced memory corruption.

Why it matters to the business

Any product, pipeline, or service that embeds Tesseract and loads untrusted or third-party language/model files (.traineddata) can be crashed, disrupting OCR workflows, document intake, and automation. In a worst case the same local heap corruption could be turned into process compromise on hosts that run Tesseract. There is no official fixed release, the issue has been public for about 27 days, it is not listed in CISA KEV, and no mature public exploit is reported—so operational risk is driven by exposure to untrusted models rather than mass remote scanning. Downstream OCR, RPA, and document-processing stacks that vendor Tesseract inherit this risk until they isolate model loading or ship a patched engine.

How an attack unfolds

An attacker supplies a malicious Tesseract language data file containing an NT_LSTM layer whose serialized dimensions make ns_ larger than na_. The victim process loads that model (or a package that includes it) and performs ordinary recognition. On the first LSTM forward pass, WriteTimeStepPart/AddTimeStepPart copy more timesteps than the source buffer holds, corrupting adjacent heap metadata or objects. The result is typically a crash; with a carefully shaped model it may become controlled heap corruption inside the local Tesseract process. Exploitation requires the engine to load the crafted model and does not by itself provide remote unauthenticated network access. No named threat actors or ransomware campaigns are associated with this CVE, and exploit maturity is none.

How to fix it

No vendor-fixed Tesseract release is available. Do not load untrusted or unsigned .traineddata/LSTM models; restrict language-data paths to internally reviewed files only. Prefer running Tesseract in a tightly sandboxed, non-privileged process (seccomp/AppArmor/containers, no extra capabilities, minimal filesystem) so a heap smash cannot reach adjacent workloads. Inventory all products and images that vendor tesseract-ocr 5.5.3 or earlier and track upstream for a patch that bounds-checks NetworkIO::WriteTimeStepPart and NetworkIO::AddTimeStepPart (and aligns ns_ vs na_ in LSTM::Forward). Until a release exists, freeze model updates, pin known-good traineddata hashes, and disable user-supplied language packs where the product allows it.

How to confirm the fix worked

Enumerate installed Tesseract packages, containers, and statically linked binaries and treat 5.5.3 and earlier as exposed. Confirm applications only load hashed, internally approved .traineddata files and that user-writable model directories are not on the engine search path. After applying sandboxing or an eventual upstream patch, run normal recognition against approved models and verify the process no longer loads extra language files. Do not use crafted overflow models as a production test. Watch upstream tesseract-ocr release notes and source diffs for checks on WriteTimeStepPart/AddTimeStepPart and LSTM::Forward sizing.

Typical attack path

1. Obtain or create a .traineddata (or equivalent LSTM model) with an NT_LSTM layer whose ns_ exceeds na_
2. Place that model where Tesseract will load it (user language data path, application bundle, shared model store, or an update/channel the victim trusts)
3. Trigger a recognition call that uses the default LSTM engine so LSTM::Forward runs WriteTimeStepPart/AddTimeStepPart
4. Heap out-of-bounds write corrupts the process, causing denial of service or, if the heap layout is influenced, further local compromise of the OCR process

How to detect it

There are no reported in-the-wild campaigns, KEV listings, or ransomware associations, so look for local preconditions rather than a known implant. Review hosts and containers that run tesseract or link libtesseract for abnormal crashes during the first recognition after a model load (segfault/abort in the LSTM/network I/O path). Inspect language-data directories for .traineddata files that appeared outside change control, have unexpected size or entropy, or are not on the approved hash list. Correlate OCR job start, model-path arguments (-l / tessdata), and subsequent process crashes in syslog, journald, container logs, EDR process-crash events, and core dumps. Memory-corruption telemetry (ASan/heap cookies, Windows Error Reporting, systemd-coredump) mentioning tesseract around LSTM forward is more useful than network IOCs.

• *.traineddata written outside approved tessdata directories
• tesseract
• libtesseract
• LSTM::Forward
• NetworkIO::WriteTimeStepPart
• NetworkIO::AddTimeStepPart
• src/lstm/lstm.cpp
• src/lstm/networkio.cpp
• NT_LSTM
• tessdata
• --tessdata-dir
• fatal signal in tesseract
• tesseract.*segfault
• tesseract.*Aborted

What your security team should do

• Treat every Tesseract 5.5.3-or-earlier install that can load third-party or user-supplied .traineddata as in-scope even though CVSS is medium and the vector is local
• Block or quarantine untrusted language-data files at intake; allowlist hashes of approved models
• Sandbox OCR workers and drop privileges so heap corruption is contained
• Hunt for unexpected .traineddata drops and Tesseract crash dumps while waiting for an official fix
• Subscribe to tesseract-ocr releases and schedule an emergency upgrade as soon as a patched version is published
• Ask vendors of document, RPA, and scanning products whether they embed Tesseract and how they constrain model loading