Tesseract OCR CVE-2026-119339

The host application must load an attacker-controlled model: a crafted .traineddata file (or an LSTM blob fed as the TESSDATA_LSTM component) whose first WeightMatrix mode byte has bit 7 (kDoubleFlag, 0x80) clear, e.g. 0x00, passed through TessBaseAPI::Init / init_tesseract_lang_data on a build with FAST_FLOAT enabled. FAST_FLOAT is on by default in both CMakeLists.txt and configure.ac, so this is the standard build path, not a non-default configuration. The principal limiting factors are that exploitation requires the application to actually load an untrusted or externally-supplied model (user/application interaction, local vector) and that impact is limited to process termination (denial of service) with no code execution or data disclosure; deployments that only load trusted first-party models are not realistically exposed.

This is a moderate, correctly-rated issue rather than an urgent priority. The 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: exploitation requires a local vector because the attacker must get a crafted model file loaded (AV:L), needs no authentication to the Tesseract API (PR:N), but does depend on the application loading an attacker-supplied model (UI:R), and the only impact is availability (A:H) - no confidentiality or integrity loss (C:N/I:N). The vuln.today decision label is 'this_month', not act_now/emergency, which aligns with a reachable-assertion DoS. No EPSS score and no KEV status are present in the input, so there is no signal of active or widespread exploitation; absence of these is not itself evidence either way. A credible proof of concept exists (AFL fuzzing found it, the advisory gives a minimal reproduction recipe, and a regression test ships with the fix), so the flaw is demonstrably triggerable, but a PoC is not the same as active exploitation and none is claimed. The real-world risk is confined to services that load untrusted or externally-sourced .traineddata/LSTM models; a long-running host application embedding Tesseract would be aborted (observed as SIGILL) by a single bad input. For deployments that only ever load trusted, first-party models, practical risk is low.

A service that embeds Tesseract and accepts user-supplied OCR language/model data (or pulls models from an untrusted source) is handed a crafted .traineddata file whose embedded WeightMatrix mode byte has bit 7 (kDoubleFlag) clear. When the application calls TessBaseAPI::Init to load it, DeSerialize dispatches to the unimplemented DeSerializeOld path, which hits ASSERT_HOST and aborts the whole process. A public PoC reference and reproduction recipe exist, and the attack is reliable (not timing-dependent), though it requires the victim application to load the attacker's model (local vector, user/app interaction).