CVE-2026-7012 · MaxSite CMS Redirect Plugin cross-site scripting

01 · The Real Story

This is graffiti on the inside of a locked maintenance closet, not a burglar kicking in the front door

CVE-2026-7012 is an authenticated XSS in the Redirect Plugin of MaxSite CMS 109.0 through 109.3, fixed in 109.4. The vulnerable flow is the rendering of plugin settings tied to the f_all / f_all404 arguments without proper output encoding; the vendor says the fix was adding htmlspecialchars() and explicitly characterizes the issue as Self-XSS.

The vendor's LOW 2.4 is still a little generous in enterprise terms. The decisive friction is not the payload quality but the attacker position: this starts from high-privilege authenticated access to a niche CMS, then requires someone to load the affected admin page; that is already well into post-compromise territory, with narrow exposure and limited blast radius.

"This is a self-XSS in a niche CMS: already-admin to already-admin, with little real-world upgrade in attacker capability."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain CMS admin-level access

The attacker must first authenticate to the MaxSite CMS administrative interface with privileges high enough to edit Redirect Plugin settings. In practice that means a stolen admin session, shared admin credentials, or an already-compromised administrator workstation; there is no unauthenticated foothold here.

Conditions required:

Target runs MaxSite CMS 109.0-109.3
Attacker has high-privilege CMS credentials or session
Redirect Plugin settings are reachable to that role

Where this breaks in practice:

Requires prior compromise or legitimate privileged access
MFA, SSO, and admin IP restrictions should block a lot of real deployments
MaxSite CMS is a niche platform with low enterprise prevalence

Detection/coverage: External scanners generally miss this because it sits behind authentication and role checks; coverage is mostly manual testing or authenticated DAST.

STEP 02

Store script in Redirect Plugin settings

Using a browser, Burp Suite, or the public researcher write-up referenced by the CVE, the attacker submits malicious content through the vulnerable f_all / f_all404 parameters. The payload is then stored and later reflected back into the admin UI without proper encoding on vulnerable builds.

Conditions required:

Attacker can submit plugin configuration values
Application is still on a pre-109.4 build
No custom hardening already sanitizes those fields

Where this breaks in practice:

The payload lands in an admin-only path, not a public content surface
Many orgs have one or very few admins, reducing target opportunities
If the same admin inserts and later views the value, this is functionally self-XSS

Detection/coverage: WAFs rarely help because the traffic is authenticated admin traffic to legitimate endpoints; app logs may only show ordinary settings changes.

STEP 03

Trigger execution when the admin page is viewed

The script executes only when a privileged user loads the affected page in the vulnerable admin interface. With a session-bearing browser context, the payload could read DOM data, steal anti-CSRF material, or drive same-origin admin actions.

Conditions required:

A privileged user opens the affected admin page
Browser-side defenses do not neutralize the payload
The user's session is still valid

Where this breaks in practice:

Requires user interaction
Impact stays inside the already-privileged admin plane
Modern browser controls and short-lived sessions reduce practical utility

Detection/coverage: Browser telemetry, CSP violation reports if enabled, and EDR/browser isolation can sometimes catch post-render script behavior; network scanners will not.

STEP 04

Pivot to admin-side actions

If a different privileged user is targeted, the script may perform administrative actions in that user's session. That matters mainly in multi-admin environments with role separation; otherwise the attacker is just reusing privileges they already had.

Conditions required:

There is another more valuable admin user to target
Role separation exists inside the CMS
The payload can reliably drive same-origin actions

Where this breaks in practice:

Many MaxSite deployments are small and single-admin
No evidence of in-the-wild chaining or campaign use
Blast radius is local to one CMS instance

Detection/coverage: Review admin audit logs for unusual settings changes, user creation, content edits, or plugin modifications occurring from a legitimate admin browser session.

03 · Compensating Control

Lock down admin access — Require MFA, SSO, and IP-restricted access for MaxSite admin logins, because the vulnerability is only reachable after privileged authentication. For an IGNORE verdict there is no action SLA, but this is standard hardening you should keep in place as backlog hygiene.

Reduce admin sprawl — Limit who can edit plugin settings and remove dormant admin accounts so a stolen low-value credential cannot become a path into admin-side stored XSS. For an IGNORE verdict there is no action SLA; clean this up during normal access reviews.

Monitor admin setting changes — Log and review changes to Redirect Plugin configuration values, especially unusual strings or markup in redirect-related fields. For an IGNORE verdict there is no action SLA; fold this into routine CMS audit monitoring.

What doesn't work

A perimeter WAF will not meaningfully solve this, because the malicious request is legitimate authenticated admin traffic to a normal settings endpoint.
Basic network segmentation does not remove the core risk once an attacker already has privileged browser access to the admin interface.
Blindly prioritizing by public PoC exists is misleading here; the exploit still depends on privileged access and page rendering.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No evidence found of active exploitation. CISA KEV: not listed.
Proof-of-concept availability	Yes. The CVE references a public researcher report on GitHub: `wnaspy/CVE` PDF write-up.
EPSS	0.00013 from the user-supplied intel block, which is effectively floor-level exploit probability.
KEV status	Not in KEV as of the current CISA catalog page reviewed.
CVSS vector meaning	`AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:N` means remote reachability is outweighed by high privileges required and user interaction required; integrity impact is only low.
Affected versions	MaxSite CMS 109.0, 109.1, 109.2, 109.3 are marked affected in the CVE record; component called out is the Redirect Plugin.
Fixed version	109.4. The patch commit is `8a3946bd0a54bfb72a4d57179fcd253f2c550cd7`.
Vendor stance	Vendor/CNA labels it LOW 2.4 and notes it as "Self-XSS" caused by missing `htmlspecialchars()` output encoding.
Exposure population	W3Techs reports MaxSite CMS usage at less than 0.1% of websites with an identified CMS, which is a strong downward pressure on enterprise prioritization.
Disclosure and credit	Published 2026-04-26; OpenCVE exposes the CVE timeline and credits konchan (VulDB User) with coordination by the VulDB CNA Team.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to IGNORE (0.8/10)

Why this verdict

Requires high privileges first: PR:H means the attacker is already inside the admin plane, which is compounding downward pressure on severity.
User interaction is mandatory: the payload needs an admin page view before anything happens, so this is not a one-shot remote exploit.
Tiny reachable population: MaxSite CMS is a niche CMS with W3Techs showing less than 0.1% usage, which sharply limits enterprise exposure.
Low external threat signal: no KEV entry, no campaign reporting, and the supplied EPSS 0.00013 all argue against urgent patch treatment.
Blast radius is narrow: impact is confined to the local CMS admin context and mainly matters only if one privileged user can target another.

Why not higher?

Because this is not unauthenticated, not low-privilege, and not broadly internet-exploitable in the way that matters for enterprise triage. A flaw that starts with admin compromise and then needs page rendering is not a serious patch-priority driver on its own.

Why not lower?

It still reflects a real output-encoding defect and a real stored/admin-side script execution path on vulnerable builds. In a multi-admin deployment with poor session controls, one privileged user could still abuse it against another, so documenting it as a pure non-issue without any rationale would be sloppy.

06 · Verification

Crowdsourced verification payload.

Run this on the target MaxSite CMS host or against a mounted application directory. Invoke it as bash check-maxsite-cve-2026-7012.sh /var/www/html/maxsite with read access to the CMS files; no root is required unless the webroot is restricted. The script checks the core version in application/libraries/maxsite_lib.php and outputs VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check-maxsite-cve-2026-7012.sh
# Detects likely exposure to CVE-2026-7012 in MaxSite CMS based on installed version.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE

set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "UNKNOWN - usage: $0 /path/to/maxsite" >&2
  exit 3
fi

VERFILE="$TARGET/application/libraries/maxsite_lib.php"
if [[ ! -f "$VERFILE" ]]; then
  echo "UNKNOWN - version file not found: $VERFILE"
  exit 2
fi

version=$(grep -E "public \$version = '[0-9]+\.[0-9]+';" "$VERFILE" 2>/dev/null | sed -E "s/.*'([0-9]+\.[0-9]+)'.*/\1/" | head -n1)
if [[ -z "$version" ]]; then
  echo "UNKNOWN - unable to parse MaxSite CMS version from $VERFILE"
  exit 2
fi

major=${version%%.*}
minor=${version##*.}

if [[ "$major" =~ ^[0-9]+$ && "$minor" =~ ^[0-9]+$ ]]; then
  if (( major < 109 )); then
    echo "UNKNOWN - parsed version $version is outside the CVE's stated affected range"
    exit 2
  elif (( major == 109 && minor <= 3 )); then
    echo "VULNERABLE - MaxSite CMS version $version (affected: 109.0-109.3, fixed: 109.4)"
    exit 1
  elif (( major > 109 || (major == 109 && minor >= 4) )); then
    echo "PATCHED - MaxSite CMS version $version (fixed in 109.4+)"
    exit 0
  fi
fi

echo "UNKNOWN - unable to classify parsed version $version"
exit 2