Turms AI-Serving
CVE-2025-66908
MEDIUM
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach OCR upload endpoint unauthenticated
-
DeliveryCraft non-image file with image/* Content-Type
-
ExploitBypass @FormData image validation
-
ExecutionStore web shell or HTML payload
-
ImpactTrigger code execution or stored XSS on access
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V5 - File Handling File type validation, storage isolation
MITRE ATT&CK
2 techniques across 2 tactics: Command and Control, Persistence The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires reaching the OCR image-upload endpoint exposed by the Turms AI-Serving module's OcrController, which relies on the @FormData(contentType = MediaTypeConst.IMAGE) annotation that is not actually enforced; the attacker simply sets the Content-Type header to 'image/*' or uses an image file extension to bypass the check. No authentication or user interaction is required per the CVSS vector (PR:N/UI:N). The key LIMITING factors are: only Turms AI-Serving v0.10.0-SNAPSHOT and earlier are affected (a pre-release snapshot, not a GA build); the AI-Serving module with the OCR upload feature must be deployed and network-reachable; and the elevated outcomes (server-side code execution, stored XSS) are NOT guaranteed by the upload itself - they depend on whether the application subsequently executes the upload directory or serves the stored file back to users, so a deployment that never serves or executes uploaded content faces only the storage of arbitrary files. |
| Impact | This is a moderate-severity file-upload validation flaw (CWE-434) whose signals point to a real but low-priority issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes trivial remote, unauthenticated, low-complexity exploitation, but the NVD base score is only 5.3 because impact is scoped conservatively to C:L/I:N/A:N - a notable tension with the description's claim of 'potential server-side code execution, stored XSS, or information disclosure.' Those higher impacts are explicitly conditional ('depending on how uploaded files are processed and served'), so the description's worst-case framing is NOT reflected in the rated impact metrics - treat RCE/XSS as unconfirmed potential, not demonstrated. Exploitation status: publicly available exploit code exists (a third-party CVE report on GitHub), but there is no CISA KEV listing and no EPSS score was provided in the input, so there is no evidence of active, widespread exploitation. No SSVC decision data was supplied. The dominant risk-reducing factor is prevalence: Turms is a niche open-source instant-messaging engine, affected only at v0.10.0-SNAPSHOT (a pre-release development snapshot), which sharply limits real-world exposure. Net assessment: a legitimate, easily triggered input-validation bug worth patching in any Turms deployment, but a low operational priority for most organizations given the narrow footprint, conditional impact, and absence of active-exploitation signals. |
| Exploit ScenarioDerived | A remote, unauthenticated attacker sends a crafted multipart upload to the Turms AI-Serving OCR endpoint, setting the Content-Type header to 'image/*' or appending an image file extension while the body actually contains a web shell, HTML, or script. Because the @FormData image constraint trusts the client-supplied Content-Type and extension rather than validating magic bytes, the non-image file is accepted and stored. A public exploit report exists; realized impact (code execution, stored XSS, or info disclosure) depends on whether and how the uploaded file is later served or processed. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 05, 2026
Improper file type validation in the Turms AI-Serving module (v0.10.0-SNAPSHOT and earlier) allows unauthenticated remote attackers to upload arbitrary files - executables, scripts, HTML documents, or web shells - to the OCR image-upload endpoint, because the OcrController's @FormData(contentType = MediaTypeConst.IMAGE) restriction validates only client-supplied Content-Type headers and file extensions rather than actual file content. Publicly available exploit code exists in the form of a published PoC report, and the issue carries a CVSS 3.1 base score of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N per NVD; our assessment adds a low integrity impact). The elevated outcomes sometimes attributed to this flaw - server-side code execution or stored XSS - are not guaranteed by the upload itself and only materialize if the deployment executes the upload directory or serves stored files back to users; a hardening-lacking deployment that does neither faces only arbitrary file storage.
RemediationAI
No vendor-released patch identified at time of analysis - the upstream Turms repository should be monitored at https://github.com/turms-im/turms for a fix to OcrController.java, and since the affected line is a 0.10.0-SNAPSHOT pre-release, teams should track the corresponding GA release before deploying the AI-Serving OCR feature. Until a fix lands, apply compensating controls at the application layer rather than relying on the annotation: perform server-side magic-byte validation (decode with ImageIO or detect via Apache Tika) and reject any upload whose content signature is not an allowlisted image format, since this costs CPU per upload but closes the header-spoofing bypass. Store uploads outside the web root under randomized, extension-stripped names and never map the upload directory to an executable handler; if that is impractical, disable script execution and directory listing on the upload path - the trade-off is that legacy consumers expecting static file serving will break. Serve any retrieved upload with Content-Disposition: attachment and X-Content-Type-Options: nosniff to neutralize stored XSS, and re-encode accepted images to a normalized format (which strips embedded scripts/polyglot payloads but may strip metadata or degrade quality). Because exploitation is unauthenticated (PR:N) and public exploit code exists, additionally restrict the OCR endpoint to trusted networks or authenticated gateways with rate limiting, and monitor upload paths for unexpected file types; NVD references are at https://github.com/turms-im/turms and the controller source linked above, with the PoC report at https://github.com/Xzzz111/public_cve_report/blob/main/CVE-2025-66908_report.md.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-434 (Unrestricted Upload of File with Dangerous Type), specifically a trust-boundary failure in which server-side validation delegates to untrusted client input. The OcrController in turms-ai-serving/src/main/java/im/turms/ai/domain/ocr/controller/OcrController.java declares @FormData(contentType = MediaTypeConst.IMAGE) with the intent of restricting the multipart upload to images, but this annotation is not enforced against the bytes actually received. A correct implementation would inspect file signatures (magic bytes) - for example via ImageIO decoding, Apache Tika detection, or explicit header checks for PNG/JPEG/GIF - and reject payloads whose content does not match an allowlisted image type; instead the module accepts any payload as long as the attacker sets Content-Type: image/* or appends an image extension. The affected component is the Java-based Turms instant-messaging platform's AI-Serving microservice, identified by CPE cpe:2.3:a:turms-im:turms:0.10.0-snapshot as a pre-release snapshot build rather than a GA release, and the OCR upload feature must be deployed and network-reachable for exposure. The consequences are downstream-dependent: code execution requires the uploaded file to land in an executable or otherwise processable location, stored XSS requires the file to be served back to a browser with a content type that renders scripts, and information disclosure requires the attacker to reach or guess the stored path.
Know when Turms gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Unauthenticated remote upload is trivial (AV:N/AC:L/PR:N/UI:N); code execution and XSS are conditional on serving/processing, so impact stays Low integrity/Low confidentiality with S:U rather than full RCE.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
DescriptionCVE.org
Turms AI-Serving module v0.10.0-SNAPSHOT and earlier contains an improper file type validation vulnerability in the OCR image upload functionality. The OcrController in turms-ai-serving/src/main/java/im/turms/ai/domain/ocr/controller/OcrController.java uses the @FormData(contentType = MediaTypeConst.IMAGE) annotation to restrict uploads to image files, but this constraint is not properly enforced. The system relies solely on client-provided Content-Type headers and file extensions without validating actual file content using magic bytes (file signatures). An attacker can upload arbitrary file types including executables, scripts, HTML, or web shells by setting the Content-Type header to "image/*" or using an image file extension. This bypass enables potential server-side code execution, stored XSS, or information disclosure depending on how uploaded files are processed and served.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.
Malicious file upload attacks exploit insufficient validation when web applications accept user-provided files.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
Affected Products (CPE)CVE.org
Memory exhaustion denial of service in Turms AI-Serving (v0.10.0-SNAPSHOT and earlier) allows remote attackers to crash
Authenticated users on Turms IM Server v0.10.0-SNAPSHOT and earlier can exploit a broken access control flaw (CWE-284) i
Cross-site request forgery in Turms Admin API through v0.10.0-SNAPSHOT allows remote attackers to cause an authenticated
Turms Server (turms-im:turms) v0.10.0-SNAPSHOT and earlier retains administrator passwords in cleartext in the rawPasswo
NVD
CVE.org
EPSS
GitHub
VulDB
Exploit-DB