MaxSite CMS CVE-2026-70553

The install endpoint must be network-reachable and still responsive to POST requests after installation has already completed - the core defect is that the installer does not disable itself, so an attacker submits a db_dbprefix parameter whose value contains a single quote to escape the string literal in application/config/database.php. The concrete prerequisite is an unauthenticated HTTP POST to the install endpoint with a malicious db_dbprefix; the concrete limiter is deployment hygiene - installations that have deleted or access-restricted the install directory (or made the config file non-writable by the web server) are not exploitable. No authentication, user interaction, or non-default feature toggle is otherwise required (PR:N/UI:N).

This is a genuine high-priority issue, not a high-score-low-risk artifact. The CVSS 4.0 vector aligns cleanly with the description: AV:N/AC:L/AT:N/PR:N/UI:N means fully remote, low-complexity, unauthenticated exploitation with no user interaction, and VC:H/VI:H/VA:H reflect full compromise of the host application, consistent with arbitrary PHP execution. No EPSS score, SSVC decision, or KEV listing was provided in the input, so probabilistic and active-exploitation signals cannot be quantified - absence of EPSS/KEV should not be read as low risk given the trivial exploitation profile. The main real-world limiter is that the install endpoint must remain reachable; the vulnerability's own premise (exploitable 'after installation is complete') indicates the endpoint is not properly locked down, which is a common misconfiguration. No public exploit is identified at time of analysis, but the VulnCheck advisory documents the exact mechanism, lowering the bar to weaponization.

An attacker locates an internet-facing MaxSite CMS instance whose install endpoint is still reachable and sends a single crafted unauthenticated POST containing a db_dbprefix value like prefix'; system($_GET[c]); //, which breaks out of the PHP string in application/config/database.php. The injected code is written to disk and then executed by the web server on the next and every subsequent page load, giving durable command execution as the web-server user. Given AV:N/AC:L/PR:N/UI:N, this requires only network reachability and no credentials; no public exploit is identified at time of analysis but the VulnCheck advisory describes the full technique.