CVE-2026-88048

What it actually does

In Tesseract 5.5.3 and earlier, FullyConnected::DeSerialize does not check that deserialized LSTM layer scalars ni_ and no_ match the weight-matrix dimensions. During FullyConnected::Forward, MatrixDotVector writes w.dim1() results into a temp_line buffer sized from no_ and reads w.dim2()-1 inputs from a curr_input buffer sized from ni_. A crafted .traineddata NT_SOFTMAX layer with inconsistent dimensions therefore causes a heap out-of-bounds write and read on the default LSTM engine, leading to heap corruption, process crash, information disclosure from adjacent heap memory, or potentially attacker-influenced memory corruption in the OCR process.

Why it matters to the business

Any product or pipeline that loads Tesseract language or LSTM model files from untrusted, user-supplied, or weakly controlled sources (document ingestion, ID/KYC scanning, invoice and mailroom OCR, RPA, or shared model repositories) can suffer OCR-service crashes, corrupted recognition results, or leakage of in-process data. There is no fixed upstream release as of this review (published 2026-09-10; about 27 days without a patch), so exposure persists until organizations restrict model loading, sandbox the engine, or apply a future vendor fix. Confidentiality, integrity of OCR output, and availability of document-processing workflows are all in scope. This is not listed in CISA KEV and no in-the-wild or ransomware use is indicated; exploit maturity is none, but the attack surface is local file load rather than remote unauthenticated network access.

How an attack unfolds

An attacker who can cause the default LSTM engine to load a malicious .traineddata file supplies an NT_SOFTMAX FullyConnected layer whose ni_/no_ scalars disagree with the serialized weight matrix. When Tesseract deserializes the layer and later runs Forward, MatrixDotVector operates on undersized heap buffers, producing out-of-bounds heap reads and writes. Depending on heap layout this can crash the OCR process, disclose adjacent memory, or corrupt heap metadata and application objects. Delivery is typically via a planted or substituted language-data file, a malicious model in a shared tessdata directory, or a document-processing path that accepts custom traineddata—not a network packet to a listening service. No named threat actors or campaigns are associated with this CVE, and public exploit maturity is none.

How to fix it

No official fixed Tesseract release is available. Do not load .traineddata files from untrusted users, the internet, or unsigned/unverified packages; pin tessdata to internally approved, integrity-checked models (hashes/signatures) and make model directories read-only to the OCR service account. Prefer running tesseract (and embeddings of libtesseract) in a tight sandbox or container with no writable tessdata path, minimal privileges, and no access to secrets. Inventory all tesseract-ocr / Tesseract 5.5.3 and earlier deployments, including bundled copies in document platforms, and track upstream for a patch that validates ni_/no_ against weight-matrix dimensions in FullyConnected::DeSerialize; apply that upgrade as soon as it ships. If custom LSTM models are required, generate them only from trusted training pipelines and reject NT_SOFTMAX layers that fail dimension consistency checks.

How to confirm the fix worked

Enumerate installed Tesseract packages, containers, and statically linked libtesseract and confirm versions are 5.5.3 or earlier until a fix exists. List tessdata / TESSDATA_PREFIX paths and verify every .traineddata file against known-good hashes; alert on unexpected files or writes. Code review or binary inspection can confirm whether FullyConnected::DeSerialize still assigns ni_/no_ without comparing them to the weight matrix. After a future patch, rebuild/upgrade, then regression-test OCR with approved models and confirm the engine rejects or safely fails closed on dimension-mismatched NT_SOFTMAX layers without crashing. Do not use live malicious models as a production test.

Typical attack path

1. Obtain influence over a .traineddata (tessdata) file that the target Tesseract LSTM engine will load—via writable model directory, supply-chain substitution, or a feature that accepts custom language data.
2. Craft an NT_SOFTMAX FullyConnected layer whose deserialized ni_ and no_ scalars are inconsistent with the weight-matrix dimensions.
3. Trigger OCR (or an explicit model/init path) so FullyConnected::DeSerialize then FullyConnected::Forward / MatrixDotVector run on the malicious layer.
4. Observe crash, heap corruption, or information disclosure in the OCR process; optionally retry with adjusted dimensions if attempting more controlled corruption.
5. Abuse the resulting crash or memory corruption against the host application (denial of service, leaked OCR-adjacent data, or further process compromise if other primitives exist).

How to detect it

Hunt for process crashes and heap-allocator aborts in tesseract, libtesseract, or host applications that embed OCR, especially around LSTM/Forward after a model load. Review file-integrity and audit logs on tessdata and TESSDATA_PREFIX directories for unexpected .traineddata creates or modifications. Application logs that record loaded language data, --tessdata-dir, or TESSDATA_PREFIX help identify which model was in use at crash time. Core dumps or sanitizer/ASAN reports citing fullyconnected.cpp, weightmatrix.cpp, MatrixDotVector, or NT_SOFTMAX are investigative leads, not proof of targeted exploitation. No named APT activity is documented; treat isolated crashes after a new model file as higher priority than routine OCR failures. Network IOCs are not expected because exploitation is local model load.

• *.traineddata
• TESSDATA_PREFIX
• --tessdata-dir
• NT_SOFTMAX
• FullyConnected::Forward
• FullyConnected::DeSerialize
• MatrixDotVector
• src/lstm/fullyconnected.cpp
• src/lstm/weightmatrix.cpp
• tesseract
• libtesseract

What your security team should do

• Treat untrusted .traineddata load as an unpatched memory-corruption input; block user-supplied and unsigned models immediately.
• Inventory Tesseract 5.5.3 and earlier (packages, containers, embedded libtesseract) and lock tessdata directories to read-only trusted content.
• Sandbox OCR workers (seccomp/AppArmor/containers, non-root, no secrets) so a crash or heap corruption cannot reach adjacent services.
• Subscribe to Tesseract/GitHub security advisories and fast-track the first release that validates FullyConnected layer dimensions.
• Add detections for unexpected tessdata writes, new .traineddata files, and repeated tesseract/libtesseract crashes; this CVE is not KEV and has no known in-the-wild exploitation, but 27 days without a patch warrants compensating controls now.