CVE-2025-66908

5.3 MEDIUM

📋 TL;DR

This vulnerability allows attackers to upload arbitrary files including executables, scripts, or web shells by bypassing file type validation in Turms AI-Serving's OCR functionality. The system only checks Content-Type headers and file extensions without validating actual file content. Organizations using Turms AI-Serving module v0.10.0-SNAPSHOT or earlier are affected.

💻 Affected Systems

Products:
  • Turms AI-Serving module
Versions: v0.10.0-SNAPSHOT and earlier
Operating Systems: All platforms running Java
Default Config Vulnerable: ⚠️ Yes
Notes: Only affects systems with OCR functionality enabled and file upload endpoints accessible.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Server-side code execution leading to complete system compromise, data exfiltration, or ransomware deployment.

🟠

Likely Case

Upload of malicious files leading to stored XSS, information disclosure, or limited file system access.

🟢

If Mitigated

File uploads blocked or quarantined with no impact on system integrity.

🌐 Internet-Facing: HIGH - Directly exploitable via web interface with minimal technical requirements.
🏢 Internal Only: MEDIUM - Requires internal network access but still exploitable by authenticated users.

🎯 Exploit Status

Public PoC: ⚠️ Yes
Weaponized: LIKELY
Unauthenticated Exploit: ✅ No
Complexity: LOW

Exploitation requires access to upload endpoint but no authentication bypass needed. Public report includes technical details.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Not yet released

Vendor Advisory: https://github.com/turms-im/turms

Restart Required: Yes

Instructions:

1. Monitor Turms GitHub repository for security updates. 2. Apply patch when available. 3. Restart Turms AI-Serving service.

🔧 Temporary Workarounds

Implement server-side file validation

all

Add magic byte validation to OcrController to check actual file signatures

Modify OcrController.java to include file signature validation using libraries like Apache Tika or custom validation

Restrict file upload endpoints

all

Use web application firewall or reverse proxy to block suspicious uploads

Configure WAF rules to validate Content-Type matches actual file content
Set up reverse proxy to scan uploaded files

🧯 If You Can't Patch

  • Disable OCR image upload functionality entirely if not required
  • Implement strict file extension whitelisting and size limits at network perimeter

🔍 How to Verify

Check if Vulnerable:

Attempt to upload a non-image file with Content-Type: image/jpeg header to OCR endpoint. If accepted, system is vulnerable.

Check Version:

Check pom.xml or build.gradle for turms-ai-serving version, or run: java -jar turms-ai-serving.jar --version

Verify Fix Applied:

Test file upload with mismatched Content-Type and actual file content. Validated systems should reject such uploads.

📡 Detection & Monitoring

Log Indicators:

  • File uploads with mismatched Content-Type and file extensions
  • Large number of failed/successful upload attempts
  • Uploads of non-image file types to OCR endpoints

Network Indicators:

  • HTTP POST requests to /ocr/upload with suspicious Content-Type headers
  • Uploads of executable files to image endpoints

SIEM Query:

source="turms-ai-serving" AND (url_path="/ocr/upload" OR url_path="/api/ocr") AND (content_type!="image/*" OR file_extension IN [".exe", ".php", ".jsp", ".sh"])

🔗 References

📤 Share & Export