MaxSite CMS CVE-2026-87928

Exploitation requires a valid MaxSite CMS account at any privilege level that has access to the admin_page upload handler - the description specifies 'any logged-in user.' The attacker must be able to reach the CMS admin panel over the network. A victim (typically an administrator or other authenticated user) must subsequently browse to the URL of the uploaded HTML file for script execution to occur. No special server configuration or non-default deployment mode is required; the vulnerability is present in default MaxSite CMS installations across all versions 0.94 through 109.6. Limiting factors are authentication (PR:L - unauthenticated remote exploitation is not possible) and victim interaction (UI:P - the payload is not self-propagating).

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P, score 5.1) reflects the principal mitigations: a valid CMS account (PR:L) is required, and a victim must navigate to the uploaded file (UI:P). Subsequent system impact is correctly scoped to SC:L/SI:L, capturing session hijack or credential theft possibilities without direct server compromise. However, in CMS deployments with multiple editor or contributor accounts - a common operational pattern - the practical authentication barrier is lower than PR:L implies in isolation. Even a mid-sized municipal IT team in sopot should treat this as urgent if their MaxSite instance supports untrusted editors, given that a public PoC is documented on GitHub and stored XSS payloads persist indefinitely until manually removed. EPSS data is not provided in the input. No KEV listing is present, so widespread active exploitation is unconfirmed. The publicly available exploit code raises the practical risk above the 5.1 base score, particularly for administrator session-hijacking scenarios where the victim URL could be embedded in content or shared.

An attacker holding any low-privilege CMS account navigates to the admin_page upload interface and submits an HTML file containing a JavaScript payload designed to exfiltrate session cookies to an attacker-controlled server. The file is saved to the publicly accessible uploads/_pages/ directory. When an administrator subsequently browses to the uploaded file's URL - via a shared link or embedded reference in CMS content - the script fires silently, transmitting the administrator's session token and enabling account takeover. A public PoC demonstrating this exact technique is available on GitHub.