Missing Authentication for Critical Function

CVE-2026-75754 chains three flaws in ASUS Control Center Enterprise (ACC) — the centralized management platform that controls firmware updates, monitoring, and remote operations across your entire ASUS server and workstation fleet. An unauthenticated attacker sends a single HTTP request to extract the ACC encryption key (CWE-306), leverages SSRF (CWE-918) to instruct a local service to enable SSH on port 2222, then logs in with hardcoded credentials (CWE-798) for a root shell. From there, the attacker has direct read/write/delete access to ACC data and remote control over every server, PC, and workstation the platform manages. All ACC versions appear affected; no patched version has been publicly confirmed as of 2026-09-05.

There is no official CVSS 3.1 score from ASUS or NVD yet, though a CVSS 4.0 vector of 10.0 has been published on threat-intelligence aggregators. A perfect 10 is warranted on paper — network-reachable, zero-auth, zero-complexity, full CIA impact with downstream scope — but it overestimates real-world exposure slightly because ACC management interfaces are typically internal-only. That said, this is a fleet-orchestration platform: compromise here IS fleet compromise. The severity is accurate for any environment where ACC is reachable from any untrusted network segment, and still extremely dangerous even when restricted to the management VLAN because any lateral-movement foothold reaches it.

Why this verdict

• Zero-auth, zero-complexity chain: The entire path from network access to root shell requires no credentials, no user interaction, and no special conditions — just HTTP access to the ACC management port. Each step follows deterministically from the previous one.
• Hardcoded credentials eliminate probabilistic barriers: Unlike brute-force or credential-stuffing chains, the hardcoded credentials are identical across every ACC installation. Once published, exploitation is deterministic and automated.
• Role multiplier: ACC is canonically a fleet-orchestration and infrastructure-management platform. 100% of ACC installations occupy the high-value 'orchestration/management' role by definition. Root on ACC = remote code execution on every managed endpoint. The blast radius is fleet-scale (up to 1,000+ managed devices per instance). This sets the verdict floor at CRITICAL per the deployment-role blast-radius rule.
• No patch available: As of 2026-09-05, no fixed version exists. The vulnerability window is open-ended until ASUS ships a patch, increasing urgency.
• Friction is minimal: The only real friction is network reachability — ACC is typically internal-facing. However, 'requires internal network access' means post-initial-access (the attacker is already inside), and management VLANs in many SMB/mid-market environments are flat or weakly segmented. This friction does not break the CRITICAL floor.

Why not higher?

This is already assessed at CRITICAL (9.5/10.0). The 0.5 reduction from a perfect 10 reflects: (1) no public PoC or hardcoded credential disclosure yet, meaning immediate mass exploitation is unlikely in the first 48 hours; (2) ACC is not typically internet-facing, so the attack requires internal network position or prior compromise; (3) ACC's installed base is smaller than mass-market products like Exchange or vCenter.

Why not lower?

Downgrading below CRITICAL is not defensible. ACC is a fleet-management platform — compromise IS fleet compromise by design. The chain requires zero authentication and uses hardcoded credentials that are identical across all installations. Even with internal-network-only exposure, any post-initial-access attacker (phishing foothold, VPN compromise, insider) reaches ACC trivially in weakly segmented environments. The blast radius is not one host — it is every managed host.

1. Isolate ACC management interface to a dedicated, hardened management VLAN immediately — ACC should only be reachable from jump hosts / PAWs used by authorized infrastructure admins. Deploy firewall rules blocking all other subnets from reaching ACC's HTTP/HTTPS and port 2222 within the noisgate mitigation SLA of 3 days. This is the single most impactful control — if attackers can't reach the interface, the chain breaks at step 1.
2. Block port 2222 outbound and inbound on ACC host firewall — The SSRF enables SSH on port 2222. A host-based firewall rule explicitly blocking port 2222 (both listen and connect) prevents the attacker from reaching the SSH service even if the SSRF succeeds. Deploy within 3 days.
3. Deploy network IDS rules for ACC key-retrieval endpoint access — Monitor for HTTP requests to the ACC encryption-key endpoint. Any request to this path from a non-admin source is a high-fidelity indicator of exploitation. Alert and block.
4. Audit ACC access logs daily until patch is available — Review ACC web server logs and SSH auth logs for anomalous access. Look for unauthenticated API calls, SSH connections on port 2222, and unexpected management operations.
5. Evaluate ACC necessity and consider temporary shutdown — If ACC is not mission-critical for daily operations, taking it offline entirely eliminates the attack surface. This is the most aggressive but most effective control. Re-enable only after ASUS ships a patch.

Run this script on the ACC server itself as root or with sudo. It checks whether the SSH service is already listening on port 2222 (indicating possible exploitation) and attempts to identify whether the ACC installation is present. Invoke with: sudo bash check_cve_2026_75754.sh

#!/bin/bash
# CVE-2026-75754 Checker for ASUS Control Center Enterprise
# Run on the ACC host as root: sudo bash check_cve_2026_75754.sh
# Exit codes: 0 = VULNERABLE, 1 = PATCHED, 2 = UNKNOWN

set -euo pipefail

VULNERABLE=0
PATCHED=0
UNKNOWN=0

echo "=== CVE-2026-75754 Assessment ==="
echo "Date: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo ""

# Check if ACC is installed
ACC_FOUND=0
if [ -d "/opt/asus" ] || [ -d "/opt/ASUS" ] || [ -d "/usr/local/asus-control-center" ]; then
    ACC_FOUND=1
    echo "[INFO] ASUS Control Center installation directory detected."
elif systemctl list-units --type=service 2>/dev/null | grep -qi 'asus\|acc'; then
    ACC_FOUND=1
    echo "[INFO] ASUS Control Center service detected."
elif docker ps 2>/dev/null | grep -qi 'asus\|acc'; then
    ACC_FOUND=1
    echo "[INFO] ASUS Control Center container detected."
else
    echo "[INFO] No ASUS Control Center installation detected on this host."
    echo "RESULT: UNKNOWN (ACC not found on this host)"
    exit 2
fi

# Check if port 2222 is already listening (indicator of active exploitation)
if ss -tlnp 2>/dev/null | grep -q ':2222 '; then
    echo "[ALERT] Port 2222 is actively listening! Possible exploitation in progress."
    LISTENER_PID=$(ss -tlnp | grep ':2222 ' | grep -oP 'pid=\K[0-9]+')
    if [ -n "$LISTENER_PID" ]; then
        echo "[ALERT] Listener PID: $LISTENER_PID"
        echo "[ALERT] Process: $(ps -p $LISTENER_PID -o comm= 2>/dev/null || echo 'unknown')"
    fi
    echo ""
fi

# Since no patched version is known yet, all ACC installs are vulnerable
if [ "$ACC_FOUND" -eq 1 ]; then
    echo "[VULN] ASUS Control Center is installed and no patched version is available."
    echo "[VULN] This installation is affected by CVE-2026-75754."
    echo "[VULN] Ensure the management interface is network-isolated and port 2222 is blocked."
    echo ""
    echo "RESULT: VULNERABLE"
    exit 0
fi

echo "RESULT: UNKNOWN"
exit 2

Sources

1. OffSeq Threat Radar — CVE-2026-75754 Advisory
2. THREATINT — CVE-2026-75754
3. ASUS Security Advisory Page
4. ASUS Control Center Data Center Edition
5. ASUS Control Center Express — Product Overview
6. ASUS Software-Defined Infrastructure for AI Data Centers