An Unauthenticated Request Can Turn ASUS Control Center Into a Root Console for the Whole Network
ASUS Control Center CVE-2026-75754 does not stop at compromising one management server. The product’s purpose is to control servers, PCs and workstations across an organisation, so a root shell on the console can place the entire managed fleet inside the blast radius.
The critical vulnerability combines three weaknesses that remove one security barrier after another. An unauthenticated network attacker can obtain an encryption key through an HTTP request, abuse server-side request forgery to make a local service enable SSH on TCP port 2222, then use hard-coded credentials to log in as root.
ASUS assigns CVE-2026-75754 the maximum CVSS 4.0 score of 10.0. The vector records a network-reachable, low-complexity path with no privileges, no user interaction and no special attack requirements. Successful exploitation can have high confidentiality, integrity and availability impact on both the vulnerable server and downstream systems.
There is no verified evidence of malicious exploitation at the time of writing. CISA’s enrichment record says Exploitation: none, and the vulnerability is not in CISA’s Known Exploited Vulnerabilities catalogue. BlackTree also found no credible public proof of concept, Nuclei template or Metasploit module. Those facts limit claims about current attacks. They do not reduce the technical impact of an unauthenticated route to root on an enterprise control plane.
The attack chain removes authentication first
The first weakness is missing authentication for a critical function. The affected interface allows a remote party to reach security-sensitive behaviour without first proving an identity.
The attacker can then obtain the encryption key needed for the next part of the chain. The CVE record describes an HTTP request that causes a local service to enable SSH on port 2222. This is the server-side request-forgery boundary: an external request can make a trusted internal component perform an action on the attacker’s behalf.
Hard-coded credentials complete the route. Once SSH is listening, the embedded username and password allow the attacker to open a root shell. No separate credential theft or local privilege-escalation exploit is required.
| Stage | Weakness | Capability gained |
|---|---|---|
| 1 | Missing authentication | Reach a critical function without an account |
| 2 | Server-side request forgery | Make a local service expose SSH on TCP port 2222 |
| 3 | Hard-coded credentials | Authenticate to the exposed service and obtain a root shell |
| 4 | Management-plane authority | Read, change or delete console data and remotely control managed systems |
The chain is unusually direct because each weakness supplies exactly what the next one needs. The encryption key is not merely sensitive data. It becomes the input that helps expose a privileged service, and the credentials for that service are already built into the product.
Root on the console can become control of the fleet
ASUS Control Center Enterprise is an integrated management platform. Its value comes from centralised visibility and remote administration, but that reach also concentrates risk. The CVE description says a successful attacker can read, write and delete data on the Control Center server and remotely control all servers, PCs and workstations managed by it.
This makes exposure analysis more important than a simple server count. One affected console may represent dozens, hundreds or thousands of downstream systems. Administrators should identify not only where the software is installed, but which endpoints it can reach, which credentials it stores and which administrative actions it can perform.
Network placement is equally important. A management console should not be treated like an ordinary business application. It belongs on a restricted administration network, with access limited to authorised operators and known management paths. Direct public exposure would turn a serious internal risk into a remotely reachable one.
ASUS and the CVE record give conflicting version guidance
The official sources do not provide one clean version boundary.
ASUS’s security RSS bulletin says users should update Control Center to version 3.1.0.9 or later. The vendor-authored CVE record separately marks versions from zero through 4.0.0.2, inclusive, as affected, with other versions listed under a default unaffected status.
Those two statements cannot safely be collapsed into “anything newer than 3.1.0.9 is fixed”, because 4.0.0.2 is numerically later and is still named as affected. The bulletin may be referring to a particular release branch, but it does not explain that distinction.
Administrators should use ASUS’s current distribution channel and confirm the fixed build for the branch they actually run. Organisations on a 4.x build should not assume they are protected merely because the version number is higher than 3.1.0.9. If the vendor’s download or support portal does not make the corrected 4.x build explicit, open a support case and obtain written confirmation before closing the remediation ticket.
No known exploitation is not the same as low urgency
CISA’s SSVC enrichment describes the vulnerability as automatable with total technical impact, while recording no known exploitation. That is a useful distinction. It says the public evidence does not support an active-campaign claim, but the disclosed attack path has few barriers if reliable exploit code emerges.
The CVE record was published on 4 September 2026 and credits Niels Teusink of Eye Security as the finder. Public disclosure gives defenders the exact service port, weakness classes and outcome, even though it does not publish reproduction steps or the hard-coded credentials.
A credible proof of concept would materially increase urgency by shortening the path from description to repeatable exploitation. For now, defenders should label the state accurately: critical and plausibly automatable, but not confirmed exploited and without a credible public PoC found.
What ASUS Control Center administrators should do
- Inventory every ASUS Control Center Enterprise installation and record the running product branch and exact build.
- Apply the latest vendor update. ASUS says to use version 3.1.0.9 or later, but customers on 4.x should confirm the corrected build because the CVE record still lists 4.0.0.2 as affected.
- Restrict the management interface to dedicated administration networks and authorised source addresses. Do not expose it directly to the public internet.
- Block unnecessary access to TCP port 2222 at network and host firewalls. Alert if the Control Center server unexpectedly begins listening on that port.
- Review SSH authentication logs, root sessions, new processes, scheduled tasks, service changes and Control Center audit records for unexplained administrative activity.
- Map the managed endpoint fleet and review remote actions initiated by the console during the possible exposure window.
- If compromise is suspected, isolate the management server, preserve logs and forensic evidence, rotate credentials and keys accessible to it, and investigate the downstream systems it could control.
- Do not treat installation of an update as proof that a previously exposed console is clean.
ASUS has not published a separate workaround in the bulletin. Segmentation and port filtering reduce exposure, but they do not repair the underlying weaknesses. They are compensating controls while organisations establish the correct fixed build and complete the update.
The real asset is the trust behind the console
A management server may look like one host in an inventory, but it represents the authority delegated to it. The credentials, remote-control channels and endpoint relationships behind that host can turn one compromise into an organisation-wide incident.
That is why this vulnerability deserves attention before attackers are observed using it. The flaw does not require a user to click, an administrator to log in or an attacker to bring separate credentials. If the management interface is reachable, the disclosed chain already explains how a request can become root and how root can become control of the network.
ASUS Control Center questions
Is the ASUS Control Center vulnerability being exploited?
No confirmed exploitation was found at the time of writing. CISA’s enrichment record says exploitation is none, and CVE-2026-75754 is not in CISA’s Known Exploited Vulnerabilities catalogue.
Is public exploit code available?
BlackTree found no credible public proof of concept, Metasploit module or Nuclei template. That can change quickly after disclosure, so exploit status should be monitored separately from the vulnerability’s technical severity.
Which version fixes the issue?
ASUS says to update to version 3.1.0.9 or later. The CVE record also says versions through 4.0.0.2 are affected. Because those statements conflict, verify the fixed build for your installed branch through ASUS’s current download or support channel.
Sources and further reading
- ASUS security advisory: Security Update for ASUS Control Center, published 4 September 2026 at 17:44:07 UTC+08:00, 11:44:07 Europe/Madrid.
- ASUS security advisory RSS feed, updated 7 September 2026 at 12:07:56 UTC, 14:07:56 Europe/Madrid.
- CVE.org vendor-authored record for CVE-2026-75754, published 4 September 2026 at 02:08:54 UTC, 04:08:54 Europe/Madrid.
- NIST National Vulnerability Database record, published 4 September 2026 at 03:17:41 UTC, 05:17:41 Europe/Madrid. CISA ADP enrichment was updated 4 September 2026 at 19:46:28 UTC, 21:46:28 Europe/Madrid.
