DeDeCMS CVE-2026-76800

Exploitation requires a valid low-privileged account on the DeDeCMS 3 instance - the CVSS 4.0 vector specifies PR:L, confirming authenticated access is a prerequisite; unauthenticated exploitation is not supported by available data. No user interaction from any victim is required (UI:N), and no special attack configuration or race condition applies (AC:L/AT:N). For post-upload code execution to succeed, the web server must permit script execution within the upload target directory and that directory must be web-accessible - a hardened deployment that strips execute permissions from upload paths would block the RCE stage while still being vulnerable to the upload itself. Exploitation is constrained to DeDeCMS 3 installations exposing the /include/dialog/select_media_post.php endpoint on a network-reachable interface.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, E:P) confirms low-complexity network exploitation by any authenticated low-privileged user, with no special attack requirements. The vendor-assigned impact metrics (VC:L/VI:L/VA:L) appear conservative for a CWE-434 flaw - in practice, successful PHP webshell upload yields full server-side code execution, implying integrity and confidentiality impacts well beyond 'Low'. No EPSS score was provided in the input data, so exploitation probability cannot be independently quantified. The vulnerability is absent from CISA KEV, indicating no confirmed widespread active exploitation at time of analysis, though the public POC meaningfully raises near-term risk. The combination of low attack complexity, low privilege requirement, and available exploit code means organizations should prioritize this regardless of the moderate numeric score - a deployment of DeDeCMS 3 at any operator, even a small one, is realistically at risk given the ease of weaponization.

An attacker holding a low-privileged DeDeCMS account (e.g., a contributor or registered user) submits a crafted multipart HTTP POST to /include/dialog/select_media_post.php, uploading a PHP webshell file via the uploadfile parameter without triggering server-side type restrictions. The file is stored in a web-accessible upload directory, and the attacker retrieves it via its direct URL, triggering arbitrary OS command execution under the web server process. A publicly available proof-of-concept lowers the technical barrier to near-trivial for this attack path.