Tesseract OCR EUVD-2026-114445

Two conditions must both hold. (1) The PAGE XML renderer must be active with polygon output - the shipped defaults page_xml_polygon=true and page_xml_level=0 are sufficient (the guard if (LEVELFLAG > 0 || (POLYGONFLAG && !skewed_flag)) at pagerenderer.cpp:929 is true on an upright page), and PAGE XML is the routine working format of OCR-D and similar digitisation stacks. (2) The input page must contain text recognised with right-to-left writing direction (Hebrew or Arabic); a Latin left-to-right page is a negative control and produces zero errors. Affected versions are 5.4.0-5.5.3 only (the renderer arrived in commit 577e8a8b; 5.3.x and earlier lack it). Limiting factors for defenders: delivery requires an operator/pipeline to process the attacker-supplied document locally (no network, no authentication, passive user interaction), and on glibc the flaw was not shown to progress beyond clean execution - observable corruption/DoS was demonstrated via sanitizer and depends on the allocator (musl, hardened_malloc, Windows debug CRT) or a concurrent multi-threaded OCR service.

Signals point to a genuine but moderate-priority memory-safety issue rather than an emergency. The vendor CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:H, base 6.9) and the vuln.today decision label 'this_month' both place this below act_now/emergency urgency. No CISA KEV listing is present and no EPSS score was supplied, so there is no evidence of active or widespread exploitation. A detailed, deterministic AddressSanitizer reproduction exists in the vendor GHSA advisory, but the advisory itself states that exploitability beyond a crash was NOT demonstrated on glibc - on glibc release builds 50 runs exited cleanly because the freed 200-byte chunk is immediately re-handed to the next ptaCopy and the doubly-freed object is the leaked ptsd copy nothing reads. The real risk lives in the cases the advisory names explicitly: non-glibc allocators (musl, hardened_malloc, Windows debug CRT), long-running multi-threaded OCR services where another thread's allocation lands in the freed chunk between frees, or future builds that remove the leaked ptsd copy. The confirmed observable effect is a heap-buffer-overflow READ in RecalcPolygonline driven by corrupted coordinates (a 250 MB numaCreate followed by an out-of-bounds read), i.e. primarily a denial-of-service/robustness problem on right-to-left pages. Note a tension to verify: the input tags list 'Information Disclosure' and the vector marks VC:L, yet the advisory demonstrates only memory corruption/crash and explicitly declines to claim exploitation - treat confidentiality/code-execution impact as unproven, not confirmed.

An attacker supplies an ordinary Hebrew or Arabic scanned page image to an OCR pipeline configured to emit PAGE XML with shipped defaults (page_xml_polygon true, page_xml_level 0); no network access or credentials are involved. As each recognised right-to-left word is processed, AppendLinePolygon frees the caller-owned accumulator and later reads and frees the same dangling pointer, producing a deterministic double free / use-after-free and feeding corrupted coordinates into RecalcPolygonline. A public PoC reference exists (the vendor advisory's AddressSanitizer reproduction on a benign Hebrew PNG); it is not verified as working exploit code, and code execution was not demonstrated on glibc.