Skip to main content

Turms AI-Serving CVE-2025-66908

MEDIUM
Unrestricted Upload of File with Dangerous Type (CWE-434)
2025-12-19 cve@mitre.org
5.3
CVSS 3.1 · Vendor: mitre
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach OCR upload endpoint unauthenticated
  2. Delivery
    Craft non-image file with image/* Content-Type
  3. Exploit
    Bypass @FormData image validation
  4. Execution
    Store web shell or HTML payload
  5. Impact
    Trigger 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.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
No patch listed yet 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

Vendor (mitre) PRIMARY 5.3 MEDIUM
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
vuln.today AI 6.5 MEDIUM

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.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

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

EPSS Score
0.4%
Top 64% exploitable
Prevalence
Low
niche open-source IM engine, affected only at pre-release snapshot
Exploit
POC
Public exploit code exists
Data Quality
5 sources
Confidence: Medium

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.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC Yes
EPSS 0.4%
Patch available No
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
Poc
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact· derived
Medium

Priority Score

46
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +26
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

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

cpe:2.3:a:turms-im:turms:0.10.0-snapshot:*:*:*:*:*:*:*

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy