Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify MaxSite CMS target
-
DeliveryForge ci_session cookie signed with hardcoded key
-
ExploitEmbed serialized malicious object
-
ExecutionSend cookie to trigger unserialize()
-
PersistMagic methods invoke gadget chain
-
ImpactExecute PHP / corrupt application state
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V1 - Encoding and Sanitization Safe deserialization, type allowlists
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that the target run MaxSite CMS (0.78 through 109.6) still using the default hardcoded encryption/session key from application/config/config.php - the key is what lets an unauthenticated attacker forge a signed, integrity-valid ci_session cookie. No authentication or user interaction is needed to reach the vulnerable unserialize() in Session.php. The limiting factor for full remote code execution is the presence of a usable POP gadget chain among loaded PHP classes (reflected by AT:P in the CVSS 4.0 vector); without a suitable gadget, impact is bounded to PHP object injection causing application-state corruption rather than direct code execution. An operator who has already rotated the key to a unique per-install value is not exploitable via forged cookies. |
| Impact | The signals are consistent and point to a genuine high-priority issue: CVSS 4.0 vector AV:N/AC:L/PR:N/UI:N gives unauthenticated network exploitation with no user interaction, and VC:H/VI:H/VA:H reflects full compromise potential; publicly available exploit code raises real-world exploitability well beyond theoretical. The one moderating signal is AT:P (attack requirements present), which aligns with the description's caveat that full code execution depends on usable gadget classes existing in the deployment - so on some installations impact may be limited to session forgery and application-state corruption rather than direct RCE. There is no CISA KEV entry and no EPSS figure supplied, so active exploitation is not confirmed, but the combination of a hardcoded key (reliable cookie forgery) plus unrestricted unserialize means the object-injection primitive itself is dependable. Given a public PoC and unauthenticated reach, any operator running MaxSite CMS should treat this as urgent and patch or restrict access immediately rather than waiting for KEV confirmation. |
| Exploit ScenarioDerived | An attacker crafts a serialized PHP object payload targeting a known gadget chain, signs it using the publicly documented hardcoded key to produce a valid ci_session cookie, and sends it to the site with no authentication required. On deserialization the forged object's magic methods fire, corrupting application state or executing arbitrary PHP if a viable gadget class is loaded. A public PoC for this exact object-injection path already exists. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 09, 2026
PHP object injection in MaxSite CMS through version 109.6 lets unauthenticated remote attackers forge valid ci_session cookies and pass attacker-controlled serialized data to an unrestricted unserialize() call. Because the framework ships a hardcoded encryption key, an attacker can sign forged session cookies that pass integrity checks, instantiate arbitrary PHP objects, and trigger magic methods to corrupt application state or achieve remote code execution when suitable gadget classes are present. Publicly available exploit code exists (reported by VulnCheck); this is a deserialization flaw (CWE-502) with a full-impact CVSS 4.0 score of 9.2.
RemediationAI
No fixed version is identified in the available data, so treat this as No vendor-released patch identified at time of analysis and apply compensating controls while monitoring https://github.com/maxsite/cms and the VulnCheck advisory for an update. The most effective immediate fix is to eliminate cookie forgery by replacing the hardcoded encryption/session key in application/config/config.php with a unique, high-entropy per-installation value - this invalidates the attacker's ability to sign arbitrary payloads but will log out existing sessions. Where the codebase can be modified, constrain the deserialization by passing allowed_classes => false (or a strict whitelist) to unserialize() in system/libraries/Session.php, which blocks object injection at the cost of breaking any legitimate object-based session data. As a network control, restrict or filter access to the CMS (WAF rules inspecting ci_session cookie structure, or IP allow-listing the admin surface) to reduce unauthenticated exposure, accepting that a WAF signature is an imperfect stopgap. Reference exploit and analysis: https://github.com/EviL0rd/maxsite-cve6/blob/main/2026.09.08-maxsite-cms-unsafe-unserialize-object-injection.md.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MaxSite CMS is a PHP-based content management system built on a CodeIgniter-derived core; the affected logic lives in system/libraries/Session.php, which reads the ci_session cookie, verifies it against a signing key, and then deserializes its contents. The root cause (CWE-502, deserialization of untrusted data) is that unserialize() is called without an allowed_classes / class-restriction whitelist, so any serializable class reachable in the loaded codebase can be instantiated from attacker input. Compounding this, application/config/config.php contains a hardcoded encryption/session key, defeating the cookie-integrity control that would otherwise stop forgery - the attacker can compute a valid signature for arbitrary serialized payloads. CPE cpe:2.3:a:maxsite:maxsite_cms covers all versions, and the EUVD range indicates exposure from 0.78 through 109.6.
Know when Maxsite Cms gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Unauthenticated network object injection (PR:N/UI:N); AC:H because reliable code execution depends on a usable gadget chain being present, with full C/I/A impact when achieved.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
MaxSite CMS through 109.6 passes the ci_session cookie to unserialize() without class restrictions, allowing unauthenticated attackers to inject PHP objects. Attackers can forge valid session cookies using the hardcoded encryption key to trigger magic methods and corrupt application state or achieve code execution if gadget classes exist.
Technical POC Analysis
This is CWE-502: deserialization of untrusted data.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Latest POC
1 PoC candidate from github (unverified)
Sign in to open the public PoC links collected for this CVE.
Executive ViewAI
MaxSite CMS versions through 109.6 contain a critical remote code execution vulnerability exploitable by unauthenticated attackers through forged session tokens, exposing affected servers to complete compromise. Organizations cannot rely on vendor patches for immediate mitigation, as no fix is currently available. Publicly available exploit code significantly accelerates risk of active attack and requires immediate remediation.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) Take MaxSite CMS offline or restrict network access to internal only; (2) Deploy WAF rules to detect serialized PHP object markers in HTTP traffic; (3) Implement network segmentation to isolate affected CMS servers; (4) Monitor application and web logs for exploitation indicators (deserialization errors, command execution, file system changes); (5) Disable unserialize() globally via php.ini (disable_classes/disable_functions) if application architecture permits; (6) Establish immediate timeline for migration to secure, patched CMS alternative.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
More in Maxsite Cms
View allA Remote Code Execution (RCE) vulnerability at /admin/options in Maxsite CMS v180 allows attackers to execute arbitrary
Remote Code Execution (RCE) vulnerability exists in MaxSite CMS v107.5 via the Documents page. Rated critical severity (
Authentication bypass in MaxSite CMS versions 0.78 through 109.6 lets unauthenticated remote attackers forge valid admin
Local file inclusion in MaxSite CMS through 109.6 allows unauthenticated remote attackers to execute privileged PHP hand
Maxsite CMS v180 was discovered to contain multiple arbitrary file deletion vulnerabilities in /admin_page/all-files-upd
A reflected cross-site scripting (XSS) vulnerability in MaxSite CMS before V106 via product/page/* allows remote attacke
Maxsite Cms versions up to 109.1. contains a vulnerability that allows attackers to code injection (CVSS 7.3).
Persistent unauthenticated remote code execution in MaxSite CMS lets attackers POST a crafted db_dbprefix value to the i
Unauthenticated remote code execution in MaxSite CMS is possible because the application passes attacker-controlled seri
Authentication bypass in MaxSite CMS version 109.5 and earlier lets unauthenticated remote attackers reach admin-gated A
Maxsite CMS v108 was discovered to contain a stored cross-site scripting (XSS) vulnerability via the parameter f_tags at
Maxsite CMS v180 was discovered to contain a stored cross-site scripting (XSS) vulnerability via the parameter f_file_de
EUVD-2026-75112
GHSA-2phq-cm26-22pm
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB