Vulnerabilities

Tesseract OCR 5.5.3 and earlier fails to validate counts read from the legacy INTTEMP component of .traineddata files: Classify::ReadIntTemplates uses NumClassPruners, NumClasses, and NumProtoSets as loop bounds without capping them against their maximums, and writes heap pointers past the fixed-capacity ClassPruners and ProtoSets arrays. An attacker who can supply or replace a .traineddata file consumed by Tesseract triggers this during legacy-classifier initialization, before any OCR output, gaining heap corruption, a crash (denial of service), or potentially controlled corruption. All deployments running Tesseract 5.5.3 or earlier are affected, particularly applications, document pipelines, and services that load traineddata files from untrusted or user-controlled sources. No fixed release is available as of this review, and no public proof-of-concept, KEV listing, or known in-the-wild exploitation exists.

Do: No patched version is available yet, so mitigate by ensuring Tesseract only loads .traineddata files from trusted sources and treat user-supplied traineddata as untrusted input. Deployments using only LSTM-based recognition can check whether their pipelines load legacy INTTEMP components, since the flaw is reached during legacy-classifier initialization. Monitor the tesseract-ocr GitHub repository for a fixed release and upgrade promptly once published.

An issue in the Leptonica linked library (v1.79.0) allows attackers to cause an arithmetic exception leading to a Denial of Service (DoS) via a crafted JPEG file.

Tesseract OCR 5.0.0-alpha-20201231 has a one_ell_conflict use-after-free during a strpbrk call.

In tesseract 2.03 and 2.04, an attacker can rewrite an arbitrary user file by guessing the PID and creating a link to the user's file.