Authenticated unintended access to critical program parameters

CVE-2026-10521 is a forced-browsing flaw (CWE-425) in MB connect line's mbCONNECT24 / mymbCONNECT24 cloud remote-maintenance portal and Helmholz's myREX24V2 / myREX24V2.virtual appliances, all versions ≤ 2.20.1, fixed in 2.20.2. An authenticated high-privileged user can reach a hidden configuration endpoint that was never meant to be exposed to *any* user role and use it to rewrite critical program parameters — confidentiality, integrity, and availability of the affected instance all go to H. Disclosed via CERT@VDE coordination on 2026-06-23.

Vendor calls it HIGH (8.6 CVSS 4.0), and the per-instance impact triad does justify a high number in a vacuum. But the vector tells the real story: PR:H, SC:N, SI:N, SA:N — the attacker must already be an administrator, and the damage does not escape the affected component. That is not a HIGH in operational terms; that is a privileged-admin abuse path dressed up by CIA scoring inflation. Reality is MEDIUM.

Why this verdict

• PR:H is the entire game. An attacker already carrying admin credentials on a remote-maintenance portal has dozens of legitimate destructive paths; this adds one more without changing the threat model meaningfully.
• SC:N caps the blast radius. CVSS 4.0 explicitly says no subsequent system impact — the bug rewrites parameters inside the affected component and does not, on its face, escape to the OT downstream.
• No KEV, no PoC, no campaign. Fresh CERT@VDE coordinated disclosure with no public exploit code reduces near-term operational risk.
• Role multiplier: mbCONNECT24 / myREX24 are remote-maintenance gateways for industrial systems — high-value-role components. Documented chain succeeds in that role, but capability is per-instance parameter tampering, not tunnel pivot creation; blast radius caps at *host* (the portal/appliance), not *fleet* or *OT*. That keeps the floor at MEDIUM, not HIGH.
• Narrow exposure footprint. Shodan-visible mbCONNECT24 portals number in the low thousands globally — a small population compared to the affected-component categories that earn an automatic HIGH floor.

Why not higher?

HIGH requires either an unauthenticated path, scope-change to OT, or KEV/active-exploit pressure. None apply: PR:H gates the chain, SC:N caps it inside the component, and there is no in-the-wild evidence. Treating this as HIGH would mean treating *every* admin-tier post-auth bug as HIGH, which collapses the prioritization signal you have 10,000 hosts to rely on.

Why not lower?

LOW would imply the bug is hygienic or unreachable. It is neither — the affected component sits on the OT remote-maintenance path, the impact triad is genuinely VC:H/VI:H/VA:H within the instance, and a malicious or compromised admin gains a stealthier tampering channel than they had before. MEDIUM acknowledges that reality without inflating it.

1. Force-rotate all portal administrator credentials and require MFA — Because PR:H is the gating prerequisite, eliminating cheap-to-acquire admin credentials kneecaps the chain. Enforce IdP-backed MFA on every admin login; rotate any admin password older than 90 days. No mitigation SLA at MEDIUM — but treat this as a 30-day hardening sprint regardless because it pays back across many CVEs.
2. Restrict management-plane reachability to a jump host / VPN allowlist — Most mbCONNECT24/myREX24 admin interfaces have no business being reachable from arbitrary internet IPs. Bind admin endpoints behind an allowlisted VPN or bastion to compress the attack surface; budget the change inside your routine 365-day remediation window.
3. Enable and ship configuration-change auditing to the SIEM — The hidden method will show up in web access logs as an authenticated admin hitting a non-UI-linked path. Add a Sigma rule for portal admin sessions touching endpoints outside the documented API surface; pair it with config-drift alerts on parameter writes. Deploy within the same 30-day hardening sprint above.
4. Schedule upgrade to 2.20.2 on the standard change window — Vendor patch is available; treat it as a regular maintenance upgrade. noisgate remediation SLA is ≤ 365 days for MEDIUM — but most MSPs running these appliances already do quarterly firmware cycles, so realistically this lands inside 90 days.

Run on an auditor workstation that can reach each myREX24 / mbCONNECT24 appliance over HTTPS. Invoke as ./check_cve_2026_10521.sh https://portal.example.com — no credentials needed; the script reads the public version banner. Plain shell user privileges are sufficient.

#!/usr/bin/env bash
# noisgate check: CVE-2026-10521 — MB connect line / Helmholz mbCONNECT24 / myREX24V2
# Fixed in 2.20.2; anything <=2.20.1 is VULNERABLE.
# Output: VULNERABLE | PATCHED | UNKNOWN
set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "usage: $0 https://<portal-or-appliance>" >&2
  exit 2
fi

MIN_FIXED="2.20.2"

# Pull a page likely to leak the version (login page, about, or X-Powered-By).
BODY=$(curl -sk --max-time 10 -D - "$TARGET/" 2>/dev/null) || {
  echo "UNKNOWN"; exit 3; }

# Heuristics: vendors stamp version in <meta>, JS bundle path, or response header.
VER=$(printf '%s' "$BODY" \
  | grep -Eoi 'mbCONNECT24[^0-9]{0,20}([0-9]+\.[0-9]+\.[0-9]+)|myREX24[^0-9]{0,20}([0-9]+\.[0-9]+\.[0-9]+)|version[":= ]+([0-9]+\.[0-9]+\.[0-9]+)' \
  | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' \
  | head -n1)

if [[ -z "$VER" ]]; then
  echo "UNKNOWN"; exit 3
fi

# semver compare: VULNERABLE if VER < 2.20.2
ver_lt() {
  [[ "$1" == "$2" ]] && return 1
  local lower
  lower=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
  [[ "$lower" == "$1" ]]
}

if ver_lt "$VER" "$MIN_FIXED"; then
  echo "VULNERABLE (detected $VER < $MIN_FIXED)"
  exit 1
fi

echo "PATCHED (detected $VER >= $MIN_FIXED)"
exit 0

Sources

1. Vulnerability-Lookup: CVE-2026-10521
2. CERT@VDE advisories portal
3. MB connect line product security
4. Helmholz myREX24 product page
5. CWE-425: Direct Request (Forced Browsing)
6. CVSS v4.0 specification (FIRST)
7. CISA KEV catalog
8. CISA weekly vulnerability bulletin (Jun 2026)