MaxSite CMS contains a critical PHP object injection vulnerability (CVE-2026-70554, CVSS 9.8) stemming from direct passage of cookie values to unserialize(). This is not a subtle flaw — it's the textbook definition of PHP object injection, a known dangerous pattern that the PHP community has warned about since 2005 and for which language-level mitigations have existed since PHP 7.0 (2015).
The exploitation path is straightforward: an attacker crafts a serialized PHP object in a cookie, sends it, and the unserialize() call reconstructs it on the server. With common gadget chains (SoapClient, Imagick, or custom application classes), this trivializes to remote code execution. No authentication required. No admin interaction. One HTTP request.
What makes this particularly severe is the cookie vector specifically. Cookies are universally client-controlled — they're the canonical example of attacker-managed input. That this went unnoticed in review suggests either the developer didn't recognize cookies as untrusted input, or no meaningful security review occurred at all. Either interpretation points to a gap in development practice.
Your priority: determine whether MaxSite is actively maintained. Check the git history for when this code was introduced — recent commits mean active negligence, while legacy code from 2012 or earlier indicates an abandoned or poorly-stewarded codebase. Examine the PHP version running in production; if it's PHP 7+ and allowed_classes was never applied, that's a separate modernization failure on top of the original vulnerability. Audit the entire codebase for other unserialize() calls on any user-controlled input (cookies, session data, form inputs) — if this pattern exists in one place, it likely exists in others. Given the trivial exploitation path and the likelihood this is not an isolated issue, treat any unpatched MaxSite installation as fully compromised until proven otherwise.