This vulnerability exists in Quantum Networks router due to missing rate limiting and CAPTCHA protection…

CVE-2026-41037 is a missing brute-force defense issue in the Quantum Networks QN-I-470 web management interface. NVD ties the affected software to qntmnet:qn-i-470_firmware:6.1.1.b1, and the public advisory for the product family describes the vulnerable condition as unlimited failed-login attempts without rate limiting or CAPTCHA on the web UI. On paper that can end in root-level administrative control, but only after the attacker can reach the management page from the same network and only if valid admin credentials are guessable, reused, default, or weak.

The vendor HIGH rating overstates enterprise reality. This is not unauthenticated remote code execution; it is an *adjacent-network credential-guessing opportunity* whose success is dominated by deployment hygiene: whether the management UI is reachable from user/Wi-Fi segments, whether strong unique admin passwords are in place, and whether operations actually watch for repeated failures. In a flat SMB network this can bite hard; in a segmented enterprise it is usually a post-initial-access or rogue-client problem, so it lands in MEDIUM.

Why this verdict

• Down from 8.8 because AV:A is real friction: the attacker must already be on the same LAN/WLAN segment, which usually implies rogue-client access or prior compromise rather than internet-scale reachability.
• Down again because the CVE only removes throttling, not authentication itself: the attacker still needs a weak, reused, shared, or default admin password. Strong unique credentials collapse the practical exploit path.
• Down again because management-plane exposure is not universal: on enterprise AP estates, local admin pages are often isolated to management VLANs, controllers, jump hosts, or disabled in favor of centralized administration.
• Kept at MEDIUM because success is still ugly: if the two gates above are met, the attacker gets administrative control of a network device with the ability to reroute, sniff, disrupt, or pivot.

Why not higher?

There is no KEV listing, no public exploitation evidence in the reviewed sources, and the EPSS is extremely low. More importantly, the attack path stacks practical prerequisites: same-network position, reachable admin UI, and guessable credentials. That is too much friction for HIGH in an enterprise patch queue.

Why not lower?

This is not harmless hygiene. If you run flat networks, shared infrastructure passwords, or locally reachable device management from user/Wi-Fi segments, the exploit path becomes very real. A successful hit lands on a network-control point, so the impact is too operationally meaningful to push into LOW.

1. Restrict management-plane reachability — Allow the web UI only from dedicated admin jump hosts, controller networks, or a management VLAN. For a MEDIUM verdict there is no mitigation SLA, but this is worth doing now because it removes the largest amplifier in the attack chain: reachable login surface.
2. Rotate and randomize local admin credentials — Set long unique per-device or per-site admin passwords and eliminate shared defaults. There is no mitigation SLA for MEDIUM; treat this as immediate hardening while you work toward the remediation window.
3. Disable local web admin where operationally possible — If central management is available, turn off direct local administration on QN-I-470 devices. That removes the brute-force target entirely and is especially valuable for guest Wi-Fi or branch environments.
4. Alert on repeated login failures to network appliances — Create detections for bursts of failed authentications, especially from wireless user ranges, guest networks, and unmanaged endpoints. There is no mitigation SLA here, but this materially reduces dwell time if someone starts password spraying device interfaces.
5. Prefer upgrade over configuration hope — Move affected firmware off the vulnerable build after confirming the vendor-fixed image. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but do not leave version validation ambiguous.

Run this from an auditor workstation on the same network segment that can already reach the QN-I-470 management UI, not on the device itself. Invoke it as ./verify_cve_2026_41037.sh https://192.0.2.10 /login username password using a known-invalid password string; no admin privileges are needed on the workstation, but you need network access to the login endpoint and you may need to adjust the field names/path if your firmware uses a different form.

#!/usr/bin/env bash
# verify_cve_2026_41037.sh
# Check for likely absence of rate limiting / CAPTCHA on a Quantum Networks QN-I-470 web login.
# Usage: ./verify_cve_2026_41037.sh <base_url> <login_path> <user_field> <pass_field>
# Example: ./verify_cve_2026_41037.sh https://192.0.2.10 /login username password
# Exit codes: 0=PATCHED 1=VULNERABLE 2=UNKNOWN 3=USAGE

set -u

if [ "$#" -ne 4 ]; then
  echo "UNKNOWN - usage: $0 <base_url> <login_path> <user_field> <pass_field>"
  exit 3
fi

BASE_URL="$1"
LOGIN_PATH="$2"
USER_FIELD="$3"
PASS_FIELD="$4"
URL="${BASE_URL%/}${LOGIN_PATH}"
TEST_USER="noisgate_probe_user"
TEST_PASS="Noisgate-Definitely-Wrong-Password-$(date +%s)"
ATTEMPTS=5
TMPDIR="$(mktemp -d)"
trap 'rm -rf "$TMPDIR"' EXIT

command -v curl >/dev/null 2>&1 || { echo "UNKNOWN - curl not found"; exit 2; }
command -v awk >/dev/null 2>&1 || { echo "UNKNOWN - awk not found"; exit 2; }

# Fetch login page first to look for obvious CAPTCHA markers.
HTML_FILE="$TMPDIR/login.html"
HTTP_CODE=$(curl -k -sS -L -o "$HTML_FILE" -w '%{http_code}' "$URL" 2>/dev/null)
if [ -z "$HTTP_CODE" ] || [ "$HTTP_CODE" = "000" ]; then
  echo "UNKNOWN - could not reach $URL"
  exit 2
fi

if grep -Eiq 'captcha|recaptcha|hcaptcha|cf-turnstile|turnstile' "$HTML_FILE"; then
  echo "PATCHED - login page exposes CAPTCHA challenge markers"
  exit 0
fi

RATE_LIMIT_HIT=0
TOTAL_TIME=0
RESP_CODES=""
BODY_MARKERS=0

for i in $(seq 1 "$ATTEMPTS"); do
  BODY_FILE="$TMPDIR/body_$i.txt"
  HDR_FILE="$TMPDIR/hdr_$i.txt"
  METRICS=$(curl -k -sS -D "$HDR_FILE" -o "$BODY_FILE" \
    -H 'Content-Type: application/x-www-form-urlencoded' \
    --data "${USER_FIELD}=${TEST_USER}&${PASS_FIELD}=${TEST_PASS}" \
    -w '%{http_code} %{time_total}' \
    "$URL" 2>/dev/null)

  CODE=$(echo "$METRICS" | awk '{print $1}')
  TIME=$(echo "$METRICS" | awk '{print $2}')
  RESP_CODES="$RESP_CODES $CODE"
  TOTAL_TIME=$(awk -v a="$TOTAL_TIME" -v b="$TIME" 'BEGIN { printf "%.6f", a + b }')

  if grep -Eiq '429 Too Many Requests|rate limit|too many attempts|temporarily blocked|account locked|try again later' "$HDR_FILE" "$BODY_FILE"; then
    RATE_LIMIT_HIT=1
  fi

  if grep -Eiq 'invalid|incorrect|failed|unauthorized|login' "$BODY_FILE"; then
    BODY_MARKERS=$((BODY_MARKERS + 1))
  fi

done

AVG_TIME=$(awk -v total="$TOTAL_TIME" -v n="$ATTEMPTS" 'BEGIN { if (n == 0) print 0; else printf "%.3f", total / n }')

# Simple heuristic:
# - If we saw explicit throttling/lockout/rate-limit language, call PATCHED.
# - If all attempts returned quickly, with no CAPTCHA and no lockout indicators, call VULNERABLE.
# - Otherwise UNKNOWN.
if [ "$RATE_LIMIT_HIT" -eq 1 ]; then
  echo "PATCHED - observed throttling/lockout indicators (codes:$RESP_CODES avg_time:${AVG_TIME}s)"
  exit 0
fi

FAST_RESPONSE=$(awk -v avg="$AVG_TIME" 'BEGIN { if (avg < 1.5) print 1; else print 0 }')
if [ "$FAST_RESPONSE" -eq 1 ] && [ "$BODY_MARKERS" -ge 3 ]; then
  echo "VULNERABLE - repeated failed logins completed without visible CAPTCHA or throttling (codes:$RESP_CODES avg_time:${AVG_TIME}s)"
  exit 1
fi

echo "UNKNOWN - endpoint reachable but result was inconclusive (codes:$RESP_CODES avg_time:${AVG_TIME}s)"
exit 2

Sources

1. NVD CVE-2026-41037 detail
2. CISA Known Exploited Vulnerabilities Catalog
3. FIRST EPSS overview
4. FIRST EPSS API documentation
5. MITRE CWE-307
6. Quantum Networks firmware portal
7. Quantum Networks QN-I-470 product page
8. Public mirror of CERT-In advisory CIVN-2026-0200