CVE-2026-103474 in yii2-starter-kit
Summary
by MITRE • 09/30/2026
yii2-starter-kit through 4.2.0 fails to validate file types in the backend storage upload actions, allowing authenticated managers to upload PHP files. Attackers with manager role can upload PHP scripts to the web-accessible storage directory and request them to execute arbitrary code on the server.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified in yii2-starter-kit versions through 4.2.0 represents a critical failure in input validation mechanisms within the backend file management subsystem. Specifically, the application fails to adequately verify or restrict the MIME types and extensions of files uploaded by users possessing manager-level privileges. This oversight allows an authenticated attacker with sufficient permissions to bypass standard security controls that are typically designed to prevent the execution of server-side scripts via web-accessible directories. The core technical flaw lies in the upload handler logic, which likely relies on client-supplied data or insufficient server-side MIME type detection rather than strict allow-listing of safe file extensions such as images and documents. By neglecting to enforce a rigid policy that rejects executable content types like PHP, ASP, or JSP, the system inadvertently creates an entry point for remote code execution.
From an operational perspective, this vulnerability enables authenticated managers to upload malicious PHP scripts directly into web-accessible storage directories. Once uploaded, these files can be invoked via HTTP requests, leading to arbitrary command execution on the underlying server infrastructure. This scenario effectively transforms a standard file management feature into a vector for full system compromise. The impact is severe because it bypasses authentication barriers by leveraging existing valid credentials and exploits the trust placed in backend administrative functions. An attacker could use this access to exfiltrate sensitive data, install backdoors, pivot to other internal systems, or disrupt service availability through denial-of-service attacks initiated from within the application environment.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-434, which describes the unrestricted upload of files with dangerous types. It also maps closely to ATT&CK technique T1505.003, known as Web Shell: Cloud Services, where attackers deploy web shells on cloud-hosted applications to maintain persistent access and execute commands remotely. The lack of proper validation reflects a broader pattern often seen in frameworks that prioritize developer convenience over strict security defaults, highlighting the necessity for rigorous input sanitization and output encoding practices even within trusted administrative interfaces.
Mitigation strategies must focus on implementing robust file upload controls at both the application logic level and infrastructure configuration levels. Developers should enforce an allow-list approach for permitted file extensions rather than relying on deny lists or MIME type detection alone, as these can often be spoofed. Additionally, uploaded files should be stored outside of web-accessible directories whenever possible to prevent direct execution via HTTP requests. If storage within a public directory is required, the server configuration must explicitly disable script execution in those specific folders using directives such as Apache's ScriptAlias or Nginx's location block configurations that deny PHP processing for image and document types. Furthermore, implementing Content Security Policy headers and ensuring that file names are randomized to prevent path traversal attacks can provide additional layers of defense against exploitation attempts.