01 · The Real Story
An admin finds a back door to a room they were already keyholder for
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.
"PR:H means the attacker already has admin. A hidden config method an admin shouldn't reach is hygiene, not a fire — patch in the 365-day window."
02 · The Attack Path
4 steps from start to impact.
STEP 01
Obtain a high-privilege portal account
The vulnerable endpoint requires an account at administrative privilege level on the mbCONNECT24/myREX24 portal. That typically means a tenant admin, service-provider operator, or platform admin credential — not a low-tier remote-maintenance user. Acquisition routes are credential theft, insider misuse, or exploitation of a separate authentication weakness.
Conditions required:
- Valid administrator credentials for the portal/appliance
- Network reachability to the management web interface
Where this breaks in practice:
- MFA, if enabled, gates admin logins
- Admin accounts are scarce and typically monitored
- Cloud portal has IP allowlisting and tenant boundaries
Detection/coverage: Portal authentication logs and SSO/IdP signals (Okta/Azure AD/ADFS) catch interactive admin logins; most ICS-MSPs run Splunk/Sentinel detections on admin-role sign-ins.
STEP 02
Forced-browse the hidden configuration method
Once logged in, the attacker requests an undocumented URL/RPC method that the UI never links and the role model never grants. Because the server-side authorization check is missing or coarse (CWE-425), the method executes for any caller carrying a high-priv session. There is no public PoC repo at time of writing; expect a CERT@VDE advisory and possibly a Metasploit-style PR within weeks.
Conditions required:
- Knowledge of the hidden endpoint path/method name
- Active authenticated session
Where this breaks in practice:
- Endpoint name not yet public — adversary must reverse-engineer the firmware or JS bundle
- WAF / portal request logging captures unusual admin endpoints
Detection/coverage: Web access logs will show admin sessions hitting non-UI-linked paths — a clean signal for a custom Sigma rule.
STEP 03
Modify critical program parameters
The hidden method rewrites configuration values that gate the portal's runtime behavior — routing, tunnel settings, account state, or service flags depending on which method is reached. Impact is scoped to the affected component (SC:N) — the attacker can corrupt or DoS that portal/appliance and tamper with data it holds, but CVSS 4.0 explicitly says no subsequent system impact propagates downstream.
Conditions required:
- Successful step 2
- Knowledge of which parameters to alter for the desired outcome
Where this breaks in practice:
- An admin already had legitimate ways to break the same component — this is mostly a *what's logged* and *what's auditable* problem, not a new capability
- Config-change auditing on the appliance flags abnormal admin writes
Detection/coverage: Configuration-drift monitoring and the appliance's own audit log are the primary signals.
STEP 04
Possible pivot toward OT (theoretical, not in-scope per CVSS)
Because mbCONNECT24 / myREX24 mediate remote VPN tunnels into industrial controllers, a sufficiently creative tampering of routing or tunnel parameters could *theoretically* widen the attacker's reach into OT segments behind the gateway. CVSS 4.0 SC:N/SI:N/SA:N says the vendor judges this out of scope, and the documented capability is parameter modification — not new tunnel creation. Treat the OT-pivot scenario as a watch item, not a baseline assumption.
Conditions required:
- Affected box is wired into a live OT remote-maintenance tunnel
- Attacker can chain parameter rewrites into a network reachability change
Where this breaks in practice:
- OT segmentation, ICS firewall rules, and conditional-access policies above the gateway
- Vendor scope rating contradicts this path
Detection/coverage: ICS network monitors (Claroty, Dragos, Nozomi) on the downstream OT segment.
03 · Compensating Control
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.
What doesn't work
- Web Application Firewall signatures won't help until the hidden endpoint path is public — you cannot block what you cannot name.
- Network IDS/IPS at the perimeter is blind here because the traffic is authenticated HTTPS to a legitimate admin interface from a legitimate admin session.
- EDR on the appliance is irrelevant — these are sealed vendor boxes / SaaS portals; you cannot install Defender or CrowdStrike on them.
- Reducing user-tier account privilege does not affect the chain — only the administrator population is in scope.
04 · Intelligence Metadata
The supporting signals.
| In-the-wild exploitation | None observed as of 2026-06-23; CERT@VDE coordinated disclosure with no public exploit campaign. |
|---|---|
| Public PoC | None public. CERT@VDE advisory withholds endpoint details; no GitHub PoC, no Metasploit module. |
| EPSS | Not yet scored — fresh disclosure; expect <0.5% based on PR:H class precedent. |
| KEV status | Not listed by CISA KEV. |
| CVSS 4.0 vector | AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N — PR:H is the decisive constraint; SC:N keeps blast radius inside the component. |
| Affected products | MB connect line mbCONNECT24 / mymbCONNECT24, Helmholz myREX24V2 / myREX24V2.virtual, all builds ≤ 2.20.1. |
| Fixed version | 2.20.2 (vendor patch released 2026-06-23). No distro backports — these are vendor appliances/cloud. |
| Exposure population | Shodan/Censys queries for mbCONNECT24 portals return a low-thousands footprint globally — concentrated DACH region and EU industrial integrators. |
| Disclosure date | 2026-06-23. |
| Reporter | Coordinated via CERT@VDE (German industrial CERT). |
Sources.
05 · The Call
Final Verdict
↓ DOWNGRADED to MEDIUM (5.5/10)
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.
06 · Verification
Crowdsourced verification payload.
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