A vulnerability was detected in MaxSite CMS up to 109

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.

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.

1. 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.
2. 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.
3. 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.

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.

#!/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

Sources

1. NVD entry for CVE-2026-7012
2. OpenCVE record for CVE-2026-7012
3. MaxSite CMS fix commit 8a3946b
4. Vendor security update note for MaxSite CMS 109.3+/109.4
5. Public researcher write-up referenced by the CVE
6. W3Techs MaxSite CMS usage statistics
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS information page