MaxSite CMS Ships With the Same Secret. Attackers Can Forge Admin Sessions

• The Mess: MaxSite CMS ships with a hardcoded session encryption key that is never changed during installation. Anyone who knows the key can manufacture a valid administrator session.
• The Damage: An unauthenticated attacker can take over a MaxSite site without stealing a password.
• The Fix: Replace the default encryption key immediately, invalidate existing sessions, and treat affected installations as potentially compromised.

Someone forgot to change the password.

Except it isn’t a password.

It is the cryptographic key used to protect authentication sessions.

CVE-2026-87929 affects MaxSite CMS through version 109.6. The application ships with a literal value of encryption key in application/config/config.php, and installations keep using it instead of generating a unique secret.

That turns session forgery into a surprisingly simple exercise.

One Key. Every Installation.

MaxSite uses a ci_session cookie containing serialized session information protected with HMAC-SHA1.

The signing secret is supposed to be private.

It isn’t.

Because the encryption key remains hardcoded, an attacker can calculate a valid HMAC for a forged session and send the resulting cookie to the application. The server sees a correctly signed session and accepts attacker-controlled authentication data.

The forged session can contain administrator privileges.

There is no password to crack.

There is no brute force.

There is no need to compromise another account first.

The attacker simply produces something the application already considers trustworthy.

The Login Check Never Had a Chance

The vulnerable authentication flow validates session data through functions including is_login() and mso_check_allow().

Those checks depend on the integrity of the session.

Once an attacker can generate a correctly signed cookie, the application’s authentication logic is effectively operating on counterfeit credentials.

IONIX notes that successful administrative takeover can lead to site defacement, account manipulation, configuration changes and potentially arbitrary code execution through administrative functionality.

So the initial vulnerability is authentication bypass.

The eventual compromise can be much larger.

CVSS 9.8 With No Account Required

The CVSS 3.1 vector is:

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

That means:

• network reachable;
• low attack complexity;
• zero privileges;
• zero user interaction;
• high confidentiality impact;
• high integrity impact;
• high availability impact.

CVSS 4.0 gives it 9.3 Critical.

There is currently no CISA KEV entry for CVE-2026-87929, and the CVE record does not identify a vendor-provided fix or workaround.

That last part makes the situation particularly uncomfortable.

MaxSite 109.6 Is Affected

The published affected range covers MaxSite CMS 0.78 through 109.6.

The public vulnerability report also points directly at the relevant MaxSite source code:

application/config/config.php

and the session handling logic in:

application/maxsite/common/core/init.php.

This is not a theoretical dependency buried inside an obscure binary.

The problem is sitting in the application’s authentication configuration and session handling.

There Is a Second Authentication Problem

The session key is the headline issue, but the published technical analysis identifies another ugly piece of the authentication flow.

Malformed attacker-controlled session data can reach mso_de_code(). When decryption fails, the resulting false value can be converted to 0 and subsequently used in a database query. Because of MySQL’s loose type comparison, that can create another path toward authentication abuse.

The hardcoded key alone is already enough to make the CVE serious.

The additional session-handling weakness makes the authentication subsystem look even less trustworthy.

What Administrators Should Do

There is currently no confirmed upstream release fixing the issue in the CVE record.

Until a properly patched version is available, administrators should:

• replace the default encryption_key with a unique, high-entropy secret;
• invalidate all existing sessions;
• rotate administrator passwords;
• restrict the administrative interface through VPN or IP allow-listing;
• inspect logs for suspicious login activity;
• check recently modified templates, plugins and configuration files;
• review administrator accounts for unexpected additions;
• consider server-side session storage where supported.

If the site was exposed while using the default key, changing the key should be treated as containment, not proof that nothing happened.

Bugstoday Opinion

Hardcoded secrets are not sophisticated vulnerabilities.

They are failures of basic deployment hygiene.

But once that secret signs authentication cookies, the consequences stop being basic.

MaxSite effectively gave every installation the same cryptographic skeleton key and then trusted the resulting cookies as proof of identity.

An attacker doesn’t need your password when the application is willing to manufacture the session for them.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

CVE-2026-87929

VulnCheck — MaxSite CMS Authentication Bypass

MaxSite CMS — Source Repository

IONIX Threat Center

CVE.org