MaxSite CMS CVE-2026-87929

Exploitation requires only that the target runs a default/unmodified MaxSite CMS (0.78 through 109.6) whose administrator has not manually changed the encryption key in application/config/config.php - which the installer never prompts for, so default deployments are vulnerable. No credentials, no user interaction, and no non-default feature are needed; the attacker only needs network reachability to the CMS and knowledge of the public key. The main limiting factor is that an operator who has manually rotated the encryption key to a secret value is not exploitable, and exposure is bounded by the product's relatively small deployment base.

This is a genuine high-priority issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, score 9.3) describes network-reachable, low-complexity, unauthenticated exploitation with full confidentiality/integrity/availability impact on the vulnerable system, and the mechanism matches: no authentication is needed because the attacker forges the session directly. Publicly available exploit code (VulnCheck advisory plus a documented write-up) materially raises real-world risk and lowers the skill barrier. No EPSS score is provided in the input, and the CVE is not listed in CISA KEV, so there is no confirmation of active exploitation - treat this as 'exploit-ready but not confirmed in-the-wild.' The only meaningful limiting factor is deployment footprint: MaxSite CMS is a niche CMS, so exploitation is likely to be opportunistic/targeted against exposed instances rather than mass-scanned at Log4j scale. Overall the signals are internally consistent (no CVSS-vs-description conflict), which increases confidence in the 'real priority' assessment for anyone actually running the product.

An attacker locates an internet-exposed MaxSite CMS instance, retrieves the hardcoded encryption key from the public GitHub source, and crafts a ci_session cookie asserting administrator identity, signing it with a valid HMAC-SHA1 using that key. Submitting this cookie to any admin endpoint passes is_login()/mso_check_allow(), granting full admin control with no credentials; a public exploit write-up documenting the technique already exists.