Turms AI-Serving CVE-2025-66909

Requires the Turms AI-Serving OCR/image-processing feature to be deployed and network-reachable to the attacker, and the endpoint must accept attacker-supplied image files that flow into ExtendedOpenCVImage loading via OpenCV imread(). No authentication is required only when the OCR service is publicly accessible (per the description); if the module is not deployed, not exposed, or sits behind authentication or an upload size/dimension gate, exploitation is prevented or limited. The core limiting factors are therefore exposure of the OCR upload path and absence of any pre-decompression dimension/pixel-count validation - environments not running this specific AI-Serving module are unaffected.

This is a genuine but bounded availability risk, not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/A:H, base 7.5) is internally consistent with the description: a network-reachable, unauthenticated, low-complexity attack whose sole impact is availability (C:N/I:N - no data compromise). CWE-409 (improper handling of highly compressed data) correctly maps to the decompression-bomb mechanism. Exploitation signals: publicly available exploit code exists (POC referenced in the NVD report), but the CVE is NOT in CISA KEV and no EPSS score was provided in the input, so there is no evidence of active or widespread exploitation at time of analysis - POC availability and active exploitation are distinct and must not be conflated. The affected software is Turms (an open-source IM engine) at a pre-release snapshot version (0.10.0-SNAPSHOT), which materially lowers real-world priority versus a comparable 7.5 in ubiquitous software. Net: prioritize patching for anyone actually running the Turms AI-Serving/OCR module exposed to untrusted input, but treat it as a service-availability hardening item rather than a critical breach vector. Note the missing EPSS data limits precision on exploitation likelihood.

An attacker locates a publicly reachable Turms AI-Serving OCR endpoint that accepts image uploads and submits a small crafted PNG that decompresses to gigabytes in memory when OpenCV's imread() processes it. Because dimensions and pixel count are not validated before decompression, the JVM throws OutOfMemoryError and the service crashes; repeated requests sustain the denial of service. A public proof-of-concept report exists, and the low attack complexity plus lack of required authentication make this trivially repeatable against an exposed endpoint.