Skip to content
RESEARCH INDEX BREACHROAD / INTELLIGENCE NOTE

MSI RadiX AXE6600: 11 critical command-injection flaws lead to root

CVE-2026-71983 through CVE-2026-71993 affect WPS, VPN, filtering and router administration. We explain the shared weakness, exposure and response plan.

PUBLIC RESEARCH
AUTHOR
/ CEO of Breachroad · OSCP · PNPT
PUBLISHED
9 August 2026
READING TIME
11 min read
TOPIC
Vulnerabilities and CVEs
MSI RadiX AXE6600: 11 critical command-injection flaws lead to root

A series of 11 CVE records affecting the MSI RadiX AXE6600 router was published on 9 August 2026 in Poland’s time zone. Every record describes the same dangerous pattern: management-interface data reaches an operating-system command without adequate neutralisation. According to the CNA scores, a network attacker needs neither authentication nor user interaction, and successful exploitation may execute code as root.

These are not eleven parameter variants in one form. The records cover WPS, URL and MAC filtering, access control, DMZ, ALG, port forwarding and triggering, SSH and Telnet configuration, and OpenVPN. The breadth of that list suggests an architectural weakness in configuration handling, not merely an oversight in one function.

What was published

The CNA records appeared between 23:10 UTC on 8 August and 00:00 UTC on 9 August—01:10 to 02:00 CEST on 9 August in Poland. The series comprises:

CVEInput surface
CVE-2026-71983wps.cgi, PIN parameters for the 2.4/5/6 GHz bands
CVE-2026-71984URL filtering
CVE-2026-71985access control
CVE-2026-71986DMZ configuration
CVE-2026-71987ALG settings
CVE-2026-71988port forwarding
CVE-2026-71989port triggering
CVE-2026-71990SSH configuration
CVE-2026-71991Telnet configuration
CVE-2026-71992MAC filtering
CVE-2026-71993OpenVPN configuration

CVE-2026-71983 and the remaining records identify firmware through v781521 as affected. VulnCheck, the CNA, scored each flaw 9.8 under CVSS 3.1 and 9.3 under CVSS 4.0. The vectors describe network access, low complexity, no required privileges and no user interaction. The final record in the series, CVE-2026-71993, concerns the OpenVPN function.

Why command injection in a router is so serious

An appliance’s web interface often delegates network changes instead of implementing them itself. It receives a setting, stores it and invokes an operating-system utility or script that changes the firewall, VPN service or radio configuration. If the application assembles that command as text and appends an untrusted value, data can alter the command’s meaning.

Browser-side validation is not a security control because an HTTP client can send a request without the form. A denylist of characters is also fragile: shells, encodings, parsing layers and helper tools apply different rules. A safer design avoids the shell, passes arguments through a process API, permits only strictly defined values and performs the operation with the least possible privilege.

Compromising a privileged router process places an attacker beside all local-network traffic. They could alter DNS, NAT and firewall rules, establish persistence, observe connection metadata or redirect users to fraudulent services. The CVEs establish command execution and root access; those possible follow-on actions are an impact assessment, not evidence of an observed campaign.

Who is exposed

RadiX AXE6600 devices running firmware v781521 or earlier are directly affected. Priority rises sharply where the management interface is reachable from the Internet, a guest network, an IoT VLAN or another untrusted portion of the LAN. A high base score does not, by itself, establish that every device is publicly reachable.

An administrator should separate three questions:

  1. Is the specified model and firmware actually deployed?
  2. Which network segments can reach its management interface?
  3. Could the appliance have been modified before access was restricted?

Do not rely on a procurement inventory alone. Confirm the live version, role, management addresses, publishing rules, remote services and a configuration copy. A home router used for remote work may also protect access to corporate resources and should not automatically fall outside the risk inventory.

What to do now

The MSI support page for the RadiX AXE6600 is the correct location to check firmware. At publication time, the CVE records do not clearly identify the first safe release, so do not assume that reflashing the same version removes the vulnerability.

  1. Block the administration interface from the WAN and disable unused remote-management mechanisms.
  2. Restrict access to a dedicated trusted segment or a single administrative host.
  3. Disable Telnet and unused features; this is not a complete fix for the shared weakness, but it reduces surface area.
  4. Check MSI for firmware newer than the affected range and retain the version and file hash as evidence.
  5. Review DNS, forwarding, DMZ, VPN, administrator-account and firewall settings for unauthorised changes.
  6. If the interface was public or reachable from an untrusted segment, treat updating as the start of an investigation, not its conclusion.
  7. After restoring from a trusted image, rotate secrets that may have crossed the appliance or administered it.

Prioritising without relying on CVSS alone

The 9.8 score justifies urgent action, but ordering work across a larger fleet should depend on reachability and device role. Build a matrix containing firmware version, source segments able to reach the panel, router function, traffic handled and rebuild capability. An Internet-exposed appliance terminating employee VPN has a different profile from the same model sitting disconnected in storage, although a scanner assigns both the same CVSS value.

A practical scheme can use four levels. Level one is a panel reachable publicly or from a network containing unmanaged devices. Level two covers routers reachable from a broad user or IoT network. Level three is an interface limited to an administration VLAN but without host-level filtering. Level four covers powered-off, spare or physically separated devices. Every affected release still needs remediation; the level only determines order and investigation depth.

Establish whether protective rules are enforced in front of the router or by the vulnerable router itself. An ACL configured on the appliance can be altered after root compromise. An external firewall or dedicated management network provides an independent layer. The same applies to evidence: when the only log copy resides on the appliance, a privileged attacker may modify it. Forwarding events to an external collector improves the chance of preserving a timeline.

What post-update validation should prove

Closure should not depend on a screenshot showing a new firmware number. Remediation evidence needs the version read after reboot, image source, file hash, installation date and reachability tests from the WAN, guest network, IoT network and ordinary user segment. Separately confirm that Telnet remains disabled, SSH has the expected configuration, and administrator and key inventories are correct.

If the vendor has not yet published a release explicitly identified as safe, record the state as “mitigated,” not “fixed.” The risk owner needs a review date and closure condition: an official release outside the affected range, its installation and a segmentation retest. This prevents a temporary WAN block from silently disappearing weeks later during an unrelated configuration change.

Detection and restoring trust

Look for configuration changes without a corresponding ticket, new NAT rules, unusual DNS resolvers, enabled administration services, outbound connections initiated by the router and restarts at unusual times. Correlate appliance logs with DHCP, DNS, perimeter-firewall and management-system records. The absence of an EDR alert on a router is not evidence of no compromise.

Where firmware or configuration integrity cannot be established, the safer route is to rebuild from an image obtained through the official channel, manually restore a reviewed configuration and retest exposure. Importing an old backup without analysis may reinstate hostile settings.

Facts versus Breachroad conclusions

The confirmed facts are the 11 published records, firmware through v781521, an unauthenticated network vector and impact leading to root. The public records do not confirm mass exploitation or provide a complete set of attack telemetry.

Breachroad’s conclusion is that this breadth of vulnerable functions should be treated as a failure of the boundary between a web panel and a privileged operating system. Technical cybersecurity training should teach teams to measure real exposure, while an IT security audit can verify segmentation, management-plane controls and the ability to rebuild edge appliances safely.

SHARE / COPY