361,800
Total CVEs
26,223
Critical
85,816
High
1,626
CISA KEV
1,101
This Week
697 results · Page 2/28
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.
turms-im
The LazyTasks – Project & Task Management with Collaboration, Kanban and Gantt Chart plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 1.2.29. This is due to the plugin not properly validating a user's identity via the 'wp-json/lazytasks/api/v1/user/role/edit/' REST API endpoint prior to updating their details like email address. This makes it possible for unauthenticated attackers to change arbitrary user's email addresses, including administrators, and leverage that to reset the user's password and gain access to their account. It is also possible for attackers to abuse this endpoint to grant users with access to additional roles within the plugin
Sigstore Timestamp Authority is a service for issuing RFC 3161 timestamps. Prior to 2.0.3, Function api.ParseJSONRequest currently splits (via a call to strings.Split) an optionally-provided OID (which is untrusted data) on periods. Similarly, function api.getContentType splits the Content-Type header (which is also untrusted data) on an application string. As a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed Content-Type header, a call to api.ParseJSONRequest or api.getContentType incurs allocations of O(n) bytes (where n stands for the length of the function's argument). This vulnerability is fixed in 2.0.3.
linuxfoundation