CVE-2026-104890: 
PHP vulnerability analysis and mitigation

CVE-2026-104890 is an unrestricted file upload vulnerability (CWE-434) in Kunstmaan CMS's MediaBundle that allows authenticated backend users with media access to upload executable files and achieve remote code execution. The flaw exists in src/Kunstmaan/MediaBundle/Helper/File/FileHandler.php where the extension blacklist check is performed case-sensitively before the filename is lowercased for storage, enabling a bypass via mixed-case extensions (e.g., .pHp). All versions of kunstmaan/bundles-cms and kunstmaan/media-bundle prior to 7.3.2 are affected. The vulnerability was published on September 6, 2026, and assigned a CVSS v3.1 base score of 7.2 (High) (GitHub Advisory, Release Notes).

The root cause (CWE-434) lies in FileHandler::getFilePath(), which applied a case-sensitive regex against the attacker-controlled file extension to rewrite blacklisted extensions to .txt, and only afterward lowercased the extension when building the stored filename. This ordering meant a file named webshell.pHp passed the blacklist check and was written to the web-accessible public/uploads/media/ directory as webshell.php, where the web server would execute it. Two compounding weaknesses existed: the default blacklist contained only php and htaccess, leaving extensions such as phtml, php5, phar, shtml, and cgi unblocked; and blacklist values were interpolated into the regex unescaped, introducing a secondary injection risk. The fix in commit 1bbdfde normalizes the extension to lowercase before comparison and replaces the regex with a safe in_array() check (GitHub Advisory, Patch Commit).

Successful exploitation grants an attacker arbitrary code execution as the web server user (e.g., www-data), with full confidentiality, integrity, and availability impact on the affected host. The uploaded web shell is stored in a publicly accessible directory and can be triggered over HTTP without any further authentication, meaning the privilege requirement is limited to the initial upload step. From this foothold, an attacker could exfiltrate sensitive data, modify application content, pivot to internal network resources, or establish persistent backdoor access (GitHub Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the advisory date (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.416% (34th percentile), indicating a low but non-negligible probability of exploitation within 30 days. Exploitation requires authenticated access to the CMS backend media section, which limits the attack surface but does not eliminate risk in environments with multiple backend users or compromised credentials (GitHub Advisory).

1. Obtain backend credentials: Acquire valid credentials for a Kunstmaan CMS backend account with access to the media section (e.g., through phishing, credential stuffing, or insider access).
2. Log in to the admin panel: Authenticate to the CMS backend (typically at /en/admin or similar) using the obtained credentials.
3. Navigate to the media upload section: Access the Media Library or media management area within the backend.
4. Prepare the web shell: Create a PHP web shell file (e.g., <?php system($_GET['cmd']); ?>) and save it with a mixed-case extension such as webshell.pHp or webshell.PHP to bypass the case-sensitive blacklist check.
5. Upload the file: Submit the file through the media upload interface. The FileHandler::getFilePath() method checks the extension case-sensitively (.pHp does not match the blacklisted php), then lowercases it to .php when writing to disk in public/uploads/media/<uuid>/webshell.php.
6. Retrieve the stored path: Note the UUID-based path returned by the CMS for the uploaded file, or browse the media directory listing if available.
7. Execute the web shell: Send an HTTP GET request to the stored file URL (e.g., https://target.example.com/uploads/media/<uuid>/webshell.php?cmd=id) to execute arbitrary OS commands as the web server user (GitHub Advisory, Patch Commit).

• Network: HTTP GET or POST requests to public/uploads/media/<uuid>/*.php (or .phtml, .php5, .phar) from external IP addresses; outbound connections from the web server process to unexpected external hosts following such requests.
• File System: PHP or other executable script files (e.g., .php, .phtml, .php5, .phar, .shtml) present in the public/uploads/media/ directory tree; files with recently modified timestamps in that directory that do not correspond to legitimate media uploads.
• Logs: Web server access logs (Apache/nginx) showing requests to GET /uploads/media/<uuid>/<filename>.php with query parameters (e.g., ?cmd=, ?c=, ?exec=); CMS backend access logs showing media upload activity from unusual accounts or IP addresses, particularly uploads of files with mixed-case extensions.
• Process: Unusual child processes spawned by the web server worker process (e.g., sh, bash, curl, wget, python) that are not part of normal application operation (GitHub Advisory).

Upgrade kunstmaan/bundles-cms and kunstmaan/media-bundle to version 7.3.2 or later, which normalizes file extensions before blacklist comparison, expands the default blacklist to cover phtml, php5, phar, phps, shtml, cgi, pl, asp, jsp, and many others, and introduces an opt-in allowed_extensions strict allow-list (Release Notes). Note that the patch does not rename files already stored on disk — administrators should audit the public/uploads/media/ directory for existing executable files. As an immediate workaround if upgrading is not possible, configure the web server to deny script execution in the media upload directory (e.g., php_flag engine off in Apache .htaccess, or a location block in nginx). Additionally, restrict backend media access to the minimum set of trusted users (GitHub Advisory).

The vulnerability was reported by security researcher N0fl0w and coordinated by acrobat (Jeroen Thora), who also authored the patch and the release (Release Notes). The GitHub advisory notes a related but distinct vulnerability in the FormBundle (GHSA-j376-w3x3-q674) that was fixed separately in the same release. No significant broader media coverage or notable public researcher commentary beyond the official advisory has been identified.