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.

Flowise 3.1.2 contains an improper code generation control flaw (CWE-94, code injection) in its /api/v1/prediction/ API endpoint. A remote, unauthenticated attacker can send a crafted request to this endpoint to execute arbitrary code on the server hosting Flowise, achieving full confidentiality, integrity, and availability impact (CVSS 9.8) under the application's privileges. Only version 3.1.2 is named in the available data; the full range of affected versions and any patched release are not specified. As of the provided data, the issue is not listed in CISA's KEV and no public proof-of-concept or confirmed in-the-wild exploitation is known. The critical rating reflects that the flaw is network-reachable with no privileges or user interaction required.

Do: Inventory Flowise deployments and identify any running version 3.1.2; upgrade to a patched release as soon as the vendor publishes one (no fixed version is named in the current data), and monitor the Flowise GitHub repository for an official advisory. Until patched, restrict access to /api/v1/prediction/ by enforcing authentication, binding the service to internal interfaces, or adding reverse-proxy/firewall rules. Review logs for unexpected or unauthenticated requests to that endpoint as a sign of probing or exploitation.

CVE-2026-84869 is a critical authorization flaw (CWE-862 missing authorization, CWE-269 improper privilege management) in the ScreenConnect client, the endpoint-side agent of ConnectWise's widely used remote access and remote support platform, in which files can be transferred to a machine and executed during an active remote session without the expected authorization or without confirmation by the Host (technician). It is triggered in certain circumstances during an active session, with a network attack vector, low attack complexity, low privileges required, and no user interaction per the CVSS 3.1 vector. An actor who obtains or already holds access to a session context could thereby push and run files on the managed endpoint, potentially achieving code execution with high confidentiality, integrity, and availability impact (CVSS 3.1 score 9.9, scope changed). Only endpoints running the ScreenConnect client are affected; ScreenConnect servers are not impacted, and the affected client version ranges are governed by ConnectWise security advisory AV26-903 (not enumerated in the available data). The flaw is not currently known to be exploited: it is not in CISA KEV, no public proof of concept is known, and EPSS assigns a modest 0.4% probability of exploitation within the next 30 days (32nd percentile).

Do: Follow ConnectWise security advisory AV26-903 and update ScreenConnect clients to the patched version it specifies, noting that ScreenConnect servers do not require remediation. Until patching is complete, monitor active remote sessions, require Host confirmation for file transfers, and review recent sessions on high-value endpoints for unexpected transferred or executed files; given no known exploitation and the active-session prerequisite, prioritize endpoints routinely accessed remotely.