Kunstmaan CMS CVE-2026-104890

Requires a valid authenticated backend account that holds media-upload permission in Kunstmaan CMS prior to 7.3.2. Exploitation further depends on the default (or custom) blacklisted_extensions configuration still matching case-sensitively, and critically on the web server being configured to execute scripts (e.g. PHP) within the public/uploads/media/ directory - the vendor's recommended hardening of disabling script execution and sending X-Content-Type-Options: nosniff for that directory neutralizes the impact. Limiting factors: no anonymous access (credentials with the media role are mandatory), no code execution if the upload directory is served as static/non-executable content, and the mixed-case bypass path specifically targets the pre-7.3.2 handler logic.

This is a genuine but access-gated code-execution flaw rather than a mass-exploitation emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, base 7.2) correctly captures that exploitation is network-reachable with low complexity and no user interaction, but gated behind authentication (PR:H) - the description confirms this by requiring 'an authenticated backend user with media access.' Impact is full compromise (C:H/I:H/A:H) because a successful upload yields web-server code execution (CWE-434). No EPSS score, no CISA KEV listing, and no public POC were provided in the intelligence set, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk hinges on how liberally media-upload roles are delegated: the input labels this PR:H, but the described 'media access' permission is often granted to ordinary content editors rather than administrators, so the real-world barrier may be closer to PR:L than PR:H - verify the privilege model against your role configuration. Overall this is a priority for any Kunstmaan deployment that grants backend media access to semi-trusted users, but not a drop-everything internet-wide threat given the authentication requirement and the niche product footprint.

A content editor or other backend user who has been granted media-upload rights uploads a file named 'webshell.pHp'; the case-sensitive blacklist check fails to match the mixed-case extension, and the handler then lowercases it to 'webshell.php' and writes it into the web-accessible media directory. The attacker then requests that URL, and because the web server executes PHP in that directory, their code runs with web-server privileges. No public exploit code was identified, but the mechanism is fully documented in the vendor advisory and patch commit.