Tesseract OCR EUVD-2026-114451

Exploitation requires the target application to load an attacker-controlled .traineddata language model file through Tesseract's GENERIC_2D_ARRAY::DeSerialize(TFile*) path; the crafted file must encode matrix dimensions as negative int32 values (e.g. 0xFFFFFFFF = -1) or as 65535×65535 to bypass the signed 'size > UINT16_MAX' check. The decisive limiting factor is that only the TFile-based deserialization variant is affected (the FILE-based variant already used uint32_t and is safe), and the attacker must be able to deliver a malicious traineddata file - deployments that load only trusted, bundled language data are not practically exploitable. Affected versions are <= 5.5.1 (fixed in 5.5.4); the local vector and required user interaction mean this is not remotely triggerable without someone loading the malicious model.

This is a medium-severity denial-of-service issue, not a priority emergency. The provided CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, base 5.5) is internally consistent with the mechanism: the local attack vector and required user interaction reflect that an application or user must load an attacker-supplied .traineddata language model, and the impact is availability-only (C:N/I:N) - matching the advisory's confirmed outcome of a crash. No EPSS score was provided and the issue is NOT in CISA KEV, so there is no signal of active or widespread exploitation; exploitation status is 'no public exploit identified at time of analysis' (the references are the GHSA advisory, fixing PR, commit, and release - patch artifacts, not a working exploit). The vuln.today Decision label is 'this_month', consistent with a patchable medium-severity DoS rather than act_now/emergency. One nuance to flag explicitly: the advisory states only 'potential' heap OOB read/write beyond the crash - this is NOT confirmed as achievable code execution, so C:N/I:N remains the honest assessment and the realistic impact is denial of service. The real exposure is narrow: only deployments that load untrusted, user-supplied traineddata files are at risk; applications that ship and load only trusted bundled language data are not practically exploitable.

An application or web service that lets users supply their own Tesseract language model (.traineddata) is given a crafted file whose LSTM weight-matrix dimensions are encoded as -1 (0xFFFFFFFF) or 65535×65535. When Tesseract deserializes the matrix, the malformed dimensions bypass the size check and corrupt allocation state, causing out-of-bounds access and a crash of the OCR process. No public working exploit is identified at time of analysis, though the fixing PR includes a unit test demonstrating the malformed-input trigger.