CVE-2026-105389 in feelcrm-os
Summary
by MITRE • 10/05/2026
A security vulnerability has been detected in feelec-yishu feelcrm-os 1.0.0. This issue affects some unknown processing of the file App/Feelcrm/Crm/Controller/UploadController.class.php of the component UploadTicketFile Endpoint. Such manipulation of the argument cmd leads to unrestricted upload. The attack can be launched remotely. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through an issue report but has not responded yet.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in feelec-yishu feelcrm-os version 1.0.0 represents a critical security flaw within the application's file handling mechanisms, specifically targeting the UploadTicketFile endpoint located at App/Feelcrm/Crm/Controller/UploadController.class.php. This component is responsible for processing user-uploaded files, likely intended for ticket attachments or similar CRM-related data storage. The core of the issue lies in an insufficient validation and sanitization process regarding the command argument passed to this upload function. By manipulating this specific parameter, an attacker can bypass standard file type checks and directory restrictions that are typically enforced by web application firewalls or framework-level security defaults. This lack of rigorous input verification allows for what is technically classified as unrestricted file upload, a severe vulnerability category defined under CWE-434 in the Common Weakness Enumeration standards.
The operational impact of this flaw is significant because it enables remote code execution potential on the target server. When an attacker successfully exploits this weakness, they are not merely uploading benign files but can inject malicious scripts such as PHP web shells or other executable payloads directly into a directory that may be accessible via HTTP requests. Since the project has not yet issued patches and public exploit code is available, the window of exposure remains wide open for automated scanning tools and opportunistic attackers. The ability to upload arbitrary files effectively compromises the confidentiality, integrity, and availability of the system. An attacker could use this access to exfiltrate sensitive customer data stored within the CRM, modify application logic, or establish a persistent backdoor for further lateral movement within the internal network infrastructure.
From an offensive security perspective, this vulnerability aligns with several tactics in the MITRE ATT&CK framework. The initial exploitation phase corresponds to Initial Access via Valid Accounts if authentication is required prior to upload, or directly through Unrestricted Upload of Files with Executable Content. Once a malicious file is uploaded and executed, it facilitates Command and Control activities as the attacker gains an interactive shell on the server. This scenario highlights the critical importance of implementing strict allow-lists for permitted file extensions rather than relying solely on deny lists which can be easily bypassed through extension spoofing or MIME type manipulation. Furthermore, storing uploaded files outside the web root directory with execute permissions disabled is a fundamental mitigation strategy that would have prevented this specific exploitation vector from succeeding even if the upload itself was not fully blocked by input validation failures.
To mitigate this risk immediately in the absence of an official patch, administrators should implement reverse proxy rules or Web Application Firewall policies to block requests containing suspicious patterns in the cmd parameter associated with the UploadTicketFile endpoint. Additionally, enforcing strict file type verification on both the client and server sides is essential. Server-side validation must check not only the file extension but also the actual content signature of the uploaded data to ensure it matches the declared MIME type. It is also advisable to disable script execution in directories designated for user uploads using web server configuration directives such as Apache's Options directive or Nginx location blocks that deny PHP processing for specific paths. Until a vendor-provided fix is released, continuous monitoring of upload logs and file system integrity checks should be prioritized to detect any unauthorized modifications indicative of successful exploitation attempts.