Tesseract OCR EUVD-2026-114453

Three conditions must all hold, per the advisory: (1) the legacy OCR engine must be selected (--oem 0), which is operator-controlled only and cannot be forced by a crafted model; (2) classify_use_pre_adapted_templates must be enabled (it defaults to 0, but can be set either by the operator via -c or by a .traineddata model, since tessedit.cpp passes TESSDATA_LANG_CONFIG with SET_PARAM_CONSTRAINT_NONE); and (3) the attacker must be able to write the file at <output-basename>.a - note this derives from the OUTPUT base name, not the input image name. Limiting factors that reduce realistic risk: this is not triggered by OCRing an untrusted image nor merely by loading an untrusted language pack; it needs the legacy engine plus filesystem write access to the output path, so it applies mainly to batch pipelines or shared working directories where the input supplier can also write the output directory. No authentication-level user interaction is required once the crafted file is in place.

Signals are mostly absent or conflicting, so this scores as a low-to-moderate real-world priority despite being a memory-corruption flaw. The vuln.today decision label is 'awaiting_data', there is no CISA KEV listing and no EPSS score in the input, so there is no evidence of active or probable exploitation. The one published CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N) is internally inconsistent and effectively a placeholder: it sets all three impact metrics to None, which yields a base score of 0 and contradicts the advisory's own stated DoS/memory-corruption impact - treat it as unreliable. It also claims AV:N, but the actual trigger described is a locally planted file (the attacker must be able to write the <output-basename>.a path), so the network vector is almost certainly wrong - verify with the vendor. A full proof-of-concept (extract_inttemp.py, mkpoc.py and sanitizer build steps) is published inside the GHSA advisory and the reporter demonstrated deterministic ASan crashes against current main; however the reporter explicitly stopped at the memory-corruption primitive and did not demonstrate code execution. Weighing these together: the defect is confirmed and reproducible, but exploitation requires a chain of non-default conditions (legacy engine, a non-default config flag, and attacker write access to the output path), which points to targeted/opportunistic abuse of specific pipelines rather than widespread exploitation.

A batch OCR pipeline runs the legacy engine with pre-adapted templates enabled and writes its output to a directory that the party supplying the input can also write to. The attacker plants a crafted <output-basename>.a file whose ADAPT_CLASS_STRUCT contains file-controlled pointers in its TempProtos and Config[] members; on the next run ReadAdaptedClass raw-reads the struct and the success or reject path passes those pointers to ~ADAPT_CLASS_STRUCT and operator delete, corrupting memory and crashing the process. A complete PoC demonstrating deterministic AddressSanitizer crashes is published in the GHSA advisory, but it establishes a denial-of-service/memory-corruption primitive, not code execution.