CVE-2026-87930: Critical RCE in MaxSite CMS via ci_session unserialize() — Public PoC Emerges

TL;DR

CVE-2026-87930 is a critical PHP object injection vulnerability in MaxSite CMS through version 109.6. The application takes the ci_session cookie and passes it to PHP's unserialize() without restricting which classes can be instantiated. Because the session encryption key is hardcoded, an unauthenticated attacker can forge a valid cookie, trigger magic methods, corrupt application state, and potentially achieve remote code execution if a usable gadget chain exists in the codebase or its dependencies.

A public proof-of-concept (PoC) repository is available on GitHub, and the CVE was added to CISA's Known Exploited Vulnerabilities (KEV) catalog on 2026-09-09. NVD has not assigned a severity score, but VulnCheck-derived CVSS ratings place it at 8.1 (HIGH) under CVSS 3.1 and 9.2 (CRITICAL) under CVSS 4.0. Watchstack tags the issue as critical with an RCE classification. If you run MaxSite CMS, treat this as an urgent patch-and-hunt item.

What is CVE-2026-87930?

CVE-2026-87930 is an unsafe deserialization flaw in MaxSite CMS, a content management system built on PHP. The vulnerability resides in how the application handles the ci_session cookie. Instead of validating or restricting the classes that can be instantiated during deserialization, MaxSite CMS feeds the cookie value directly into unserialize(). This allows an attacker to inject arbitrary PHP objects into the application's runtime.

The second critical weakness is that the session encryption key is hardcoded in the product. That means an attacker does not need to obtain a valid session or authenticate in any way. They can craft a serialized payload offline, encrypt it with the known key, and send it as a cookie. The application will accept it, decrypt it, and deserialize it — triggering any magic methods defined on the injected objects.

In CWE terms, this maps to CWE-502 (Deserialization of Untrusted Data) and CWE-798 (Use of Hard-coded Credentials). The vulnerability affects MaxSite CMS through version 109.6. The source intelligence does not confirm a patched release, so version verification against the vendor is required.

Technical details

Root cause: unsafe deserialization

PHP's unserialize() function can instantiate objects of any class that is autoloadable in the application. When those objects are created, their magic methods — such as __wakeup(), __destruct(), and __toString() — are invoked automatically. If an attacker can control the serialized data, they can influence which classes are instantiated and what properties those objects hold. This is the foundation of a PHP object injection attack.

In MaxSite CMS, the ci_session cookie is passed to unserialize() without the allowed_classes option, which would otherwise restrict instantiation to a safe whitelist. That omission turns a routine session-handling operation into an injection point.

Hardcoded session key amplifies the risk

Even if an attacker can inject serialized data, they typically need to bypass any encryption or signing applied to the cookie. In this case, the session encryption key is hardcoded rather than generated per installation. That design flaw means the key is the same across all vulnerable deployments, and it can be extracted from the source code or a public PoC. An attacker can therefore forge a cookie that the application will accept and decrypt, then deserialize. No credentials, no user interaction, and no special privileges are required — only network access to the CMS endpoint that processes sessions.

Attack surface and prerequisites

The attack is unauthenticated and remote. The only prerequisite is that the MaxSite CMS instance is reachable over the network and that the session-processing endpoint is exposed. Internet-facing installations are at the highest risk, but internal deployments are also vulnerable to lateral movement or insider threats.

CVSS and severity

NVD has not published a severity score for CVE-2026-87930. VulnCheck-derived CVSS scores are available:

• CVSS 3.1: 8.1 (HIGH) — vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
• CVSS 4.0: 9.2 (CRITICAL) — vector 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

The discrepancy between the two scores reflects differences in how the metrics are calculated, but both indicate a serious vulnerability. The EPSS score is currently low at 0.00337 (27.266th percentile), which suggests that probabilistic exploitation models do not yet predict widespread exploitation. However, the presence of a public PoC and the CISA KEV listing outweigh the EPSS score for prioritization purposes.

Impact

Successful exploitation can compromise confidentiality, integrity, and availability. An attacker who can inject PHP objects may:

• Manipulate application state, alter stored data, or bypass authentication and authorization checks.
• Achieve remote code execution if a gadget chain is present in MaxSite CMS or its dependencies.
• Deploy webshells, steal credentials from configuration files, or establish persistence.
• Pivot into adjacent internal services, especially if the CMS runs with elevated privileges or has network access to other systems.

Because the entry point is unauthenticated, any reachable MaxSite CMS instance is a candidate for exploitation. The business exposure includes defacement, data tampering, and potential regulatory consequences if customer or employee data is accessed. Even where RCE is not achieved, object injection alone can corrupt sessions and application logic, causing denial of service or inconsistent behavior that is difficult to diagnose.

The CISA KEV addition on 2026-09-09 signals that exploitation has been observed in the wild or is considered highly likely. That raises the priority for defenders regardless of the EPSS score.

Exposure validation

Before you can mitigate, you need to know where MaxSite CMS is running and whether it is vulnerable. Use the following steps to validate exposure:

1. Inventory MaxSite CMS instances. Search your asset inventory, CMDB, and cloud accounts for MaxSite CMS deployments. Include internet-facing, internal, and development environments. Attackers often target forgotten staging instances.
2. Determine the version. Check the CMS version against the affected range (through 109.6). If you cannot determine the version remotely, inspect the filesystem or database. The source intelligence does not confirm a patched release, so assume any version up to 109.6 is vulnerable unless the vendor states otherwise.
3. Check network exposure. Identify which instances are reachable from the internet. Use external attack surface management (EASM) tools or a simple port scan to confirm. Pay attention to non-standard ports and reverse proxies that might expose the CMS.
4. Inspect session handling. Look for endpoints that process the ci_session cookie. These are typically login, logout, or session-refresh routes. If you can safely test, send a malformed cookie and observe whether the application attempts to deserialize it (e.g., PHP errors mentioning unserialize()).
5. Review logs for exploitation attempts. Search web server and PHP logs for unusually long or base64-like ci_session cookie values, especially from new or unrecognized source IPs. Look for PHP errors mentioning unserialize(), __wakeup, __destruct, or class-not-found warnings.
6. Check for public PoC usage. The public PoC repository on GitHub may include payloads or scanning logic. Monitor for requests that match known PoC patterns, such as specific cookie lengths or serialized object strings.

If you find vulnerable, internet-facing instances, treat them as compromised until proven otherwise. Isolate them from sensitive networks and begin incident response.

Detection and hunting

Detection should focus on both the exploitation attempt and the post-exploitation activity. The following indicators can help you hunt for CVE-2026-87930:

Network and web logs

• Requests containing unusually long or base64-like ci_session cookie values, especially from new or unrecognized source IPs.
• POST or GET requests to session-processing endpoints with malformed or oversized cookies.
• Repeated 500 errors or application crashes correlated with session cookie manipulation attempts.
• Unexpected outbound connections from the web server to unknown hosts, which may indicate post-exploitation activity.

PHP and application logs

• PHP error log entries mentioning unserialize(), __wakeup, __destruct, or class-not-found warnings around session handling.
• Sudden changes to CMS configuration, user accounts, or content that were not made by administrators.
• New or modified PHP files in web-accessible directories, particularly files with obfuscated content.

Endpoint detection and response (EDR)

• EDR alerts for php-fpm or the web server spawning shell processes such as sh, bash, or cmd.exe.
• Unusual child processes from the web server, especially those that download or execute files.
• File system changes in web directories, such as the creation of new PHP files or modification of existing ones.

Threat hunting queries

• Search for ci_session cookies with a length greater than 200 characters.
• Look for serialized object patterns such as O: or a: in cookie values.
• Correlate session cookie anomalies with subsequent administrative actions or file changes.

Mitigation and workarounds

There is no confirmed patch as of this writing. The following mitigation steps can reduce risk while you wait for a vendor update:

1. Apply vendor updates immediately when available. Monitor the MaxSite CMS project for a security release. If a patch is released, test and deploy it urgently.
2. Replace the hardcoded session encryption key. If you can modify the application, generate a unique, random secret per installation and rotate any keys that may have been exposed. This breaks the ability to forge cookies.
3. Restrict access to the session endpoint. Where possible, place the CMS behind a VPN or IP allowlist. Disable or restrict the session-processing endpoint to trusted networks.
4. Deploy a web application firewall (WAF). Configure rules to inspect cookie length and entropy, and block requests with serialized object patterns. Many WAF vendors have virtual patching capabilities; check for rules specific to CVE-2026-87930.
5. Harden PHP. Disable dangerous functions where feasible, and review autoloaded classes for gadget chains. Use allowed_classes in unserialize() calls if you can modify the code.
6. Segment the CMS environment. Run the CMS in a segmented network with least-privilege database and filesystem permissions. This limits the blast radius if exploitation occurs.
7. Monitor the CISA KEV catalog. Check for updated remediation due dates and vendor guidance. The KEV entry was added on 2026-09-09; due dates may be updated.
8. Consider taking the instance offline. If you cannot patch or mitigate, and the instance is internet-facing, taking it offline may be the safest option until a fix is available.

Timeline

• 2026-09-09: CVE-2026-87930 published. Added to CISA KEV catalog the same day.
• 2026-09-09: Public PoC repository appears on GitHub.
• Ongoing: Watchstack tags the issue as critical with an RCE classification. NVD has not assigned a severity score. Vendor patch status unknown.

Sources and references

• CISA Known Exploited Vulnerabilities Catalog
• Public PoC repository on GitHub
• Watchstack vulnerability entry
• PHP unserialize() documentation
• CWE-502: Deserialization of Untrusted Data
• CWE-798: Use of Hard-coded Credentials

How Trusteed can help

Trusteed provides continuous threat exposure management (CTEM) that helps you identify, validate, and remediate vulnerabilities like CVE-2026-87930. Our platform ingests emergent threat intelligence, including public PoCs and KEV updates, and maps them to your assets. You can:

• Discover MaxSite CMS instances across your attack surface.
• Validate exposure with safe, non-destructive checks.
• Prioritize remediation based on exploitability and business impact.
• Track mitigation progress and verify fixes.

Contact your Trusteed representative to learn more about how we can help you respond to this critical vulnerability.

FAQ

Is CVE-2026-87930 on CISA KEV?

Yes. CVE-2026-87930 was added to CISA's Known Exploited Vulnerabilities catalog on 2026-09-09. The due date for remediation is currently unknown, but KEV listing indicates that exploitation has been observed or is highly likely.

Is there a public PoC for CVE-2026-87930?

Yes. A public proof-of-concept repository is available on GitHub at https://github.com/winrarzipsexploit/CVE-2026-87930. This increases the likelihood of opportunistic scanning and exploitation.

What versions of MaxSite CMS are affected?

MaxSite CMS through version 109.6 is affected. The source intelligence does not confirm a patched release, so later versions may also be vulnerable unless the vendor states otherwise. Verify your version and check for vendor updates.

Does CVE-2026-87930 require authentication?

No. The vulnerability is unauthenticated. An attacker only needs network access to the CMS endpoint that processes the ci_session cookie. The hardcoded session key allows cookie forgery without any credentials.

What is the severity of CVE-2026-87930?

NVD has not assigned a severity score. VulnCheck-derived CVSS scores rate it 8.1 (HIGH) under CVSS 3.1 and 9.2 (CRITICAL) under CVSS 4.0. Watchstack tags it as critical with an RCE classification. The EPSS score is low (0.00337), but the public PoC and KEV listing make it a high-priority vulnerability.

Can CVE-2026-87930 lead to remote code execution?

Yes, potentially. The vulnerability allows PHP object injection. If a usable gadget chain exists in MaxSite CMS or its dependencies, an attacker can escalate to remote code execution. Even without RCE, object injection can corrupt application state and lead to data tampering or denial of service.

What should I do if I cannot patch immediately?

If a patch is not available, consider taking the instance offline or restricting access to trusted networks. Replace the hardcoded session key if possible, deploy a WAF with virtual patching, and monitor for exploitation attempts. Segment the CMS environment to limit the blast radius.

How can I detect exploitation attempts?

Look for unusually long or base64-like ci_session cookie values, PHP errors mentioning unserialize() or magic methods, unexpected outbound connections from the web server, and new or modified PHP files. EDR alerts for shell processes spawned by php-fpm are also strong indicators.

Is there a patch for CVE-2026-87930?

The source intelligence does not confirm a patched release. Monitor the MaxSite CMS project and the CISA KEV catalog for updates. If a patch becomes available, apply it immediately.