CVE-2026-23813: HPE AOS-CX Switches Allow Unauthenticated Admin Password Reset

A critical authentication bypass in HPE Aruba Networking's AOS-CX operating system allows any remote attacker to reset the administrator password on enterprise switches without presenting a single credential. The flaw, CVE-2026-23813, carries a CVSS v3.1 score of 9.8 and affects multiple generations of Aruba CX-series hardware deployed across campus networks and data centers worldwide.

Hewlett Packard Enterprise disclosed the vulnerability on March 11, 2026, alongside four companion flaws affecting the same platform. The timing matters: no public proof-of-concept code or known exploitation has been confirmed as of this writing, but the window between disclosure and weaponization for flaws of this class tends to be short. Network administrators running affected AOS-CX branches should treat this as a patching priority, not a future agenda item.

What Is HPE AOS-CX?

AOS-CX is Hewlett Packard Enterprise's cloud-native network operating system, developed under the Aruba Networking brand for the company's CX-series switches. Unlike traditional monolithic switch operating systems, AOS-CX is built on a modular Linux architecture that uses a state-database design and exposes REST APIs for automation and programmability. It powers everything from compact access-layer switches like the CX 4100i to high-capacity data center platforms like the CX 9300 and CX 10000 series.

The operating system includes a web-based management interface that allows administrators to configure devices, monitor traffic, and perform system tasks through a browser rather than a command-line session. That interface is what CVE-2026-23813 targets. Because AOS-CX is widely deployed in enterprise campus networks and data centers, a vulnerability in its management plane affects organizations of considerable size and criticality. HPE serves more than 55,000 enterprise customers globally, including roughly 90 percent of Fortune 500 companies, according to company data.

The Vulnerability: CVE-2026-23813

CVE-2026-23813 is an authentication bypass in the web-based management interface of AOS-CX. HPE's official security advisory (bulletin hpesbnw05027en_us) states that the flaw allows an unauthenticated remote actor to circumvent existing authentication controls, and that in some cases this could enable resetting the admin password. The advisory offers no additional technical detail on the precise mechanism, but post-disclosure analysis has since filled that gap.

The phrase "in some cases" in HPE's advisory is worth pausing on. It signals that the password reset outcome is not guaranteed in every exploitation attempt — the bypass itself is consistent, but what the attacker can do with that bypass may depend on the switch's current configuration state, which administrative endpoints are active, or whether the web management interface is running over HTTPS with certain hardened settings applied. HPE has not published detailed analysis of the conditions that determine whether a bypass attempt escalates to a full password reset, and the security community has not yet produced a public technical analysis that resolves this precisely. What is clear is that the authentication bypass alone — even without the password reset — is a serious condition: an unauthenticated actor who can circumvent access controls on a switch management interface has meaningful footholds even if credential replacement is not always achievable.

The CVSS v3.1 vector string is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which translates directly to the highest possible marks across the metrics that govern exploitability. The attack vector is Network, meaning the flaw is exploitable remotely without local access. Attack Complexity is Low, meaning no special conditions or race states are required. Privileges Required is None, and User Interaction is None. The Impact scores on Confidentiality, Integrity, and Availability are all High, reflecting the reality that administrative control over a switch is effectively total control over the network segments it manages.

The technical root cause, as described in post-disclosure analysis by Rescana and BeyondMachines, involves the web management interface's failure to properly validate session tokens for specific administrative endpoints, including the password reset function. An attacker can craft HTTP requests that trigger the password reset process without supplying authentication tokens or passing session validation checks. The intended security controls are bypassed at the protocol level before they have a chance to enforce anything — the interface processes the reset without confirming the requestor holds a valid authenticated session.

The vulnerability was discovered and responsibly disclosed by a security researcher identified as "moonv" through HPE Aruba Networking's official bug bounty program. The CVE identifier was reserved on January 16, 2026, and the full advisory was published on March 11, 2026.

How an Attacker Could Exploit This

The exploitation path for CVE-2026-23813 is straightforward precisely because the flaw requires nothing from the attacker in terms of prior access or setup. The web management interface on an AOS-CX switch is typically accessible over HTTPS on the switch's management IP address. If that interface is reachable from an untrusted network segment, an attacker can send crafted HTTP requests to the password reset endpoint without holding a valid session or authentication token.

Once the admin password is reset, the attacker controls the device as fully as a legitimate administrator. From that position, the consequences extend well beyond the switch itself.

With administrative access, an attacker can alter routing tables and VLAN configurations to redirect or intercept traffic, disable port security to facilitate lateral movement, pivot the compromised switch as a vantage point for deeper network reconnaissance, and lock out legitimate administrators by changing credentials again after establishing persistence. In data center environments, where AOS-CX CX 8000 and CX 9000 series switches may carry substantial east-west traffic between servers, the blast radius extends to any workload that depends on that fabric.

Corsica Technologies CISO Ross Filipek, speaking to CSO Online, noted that a successful exploit could hand attackers complete and covert control over affected network devices, with downstream effects ranging from disrupted communications to the degradation of business-critical services.

CyCognito's threat researchers noted an additional concern in their advisory: CVE-2026-23813 and CVE-2026-23814 form a realistic compound attack chain. An attacker who uses the authentication bypass to gain administrative control of a switch can then use the command injection flaw (CVE-2026-23814) to execute arbitrary commands on the underlying Linux operating system, extending the compromise from the network management plane down to the host OS level. Neither flaw alone is as damaging as both used in sequence.

That compound scenario is particularly concerning given how AOS-CX is architected. Unlike legacy switch operating systems where the management plane and the forwarding plane share tightly coupled code, AOS-CX uses a state-database (OVSDB) model in which configuration changes made through the management interface — whether via the web UI, REST API, or CLI — are committed to a central state store that the forwarding engine reads. An attacker who can write to that store through an authenticated session (gained via CVE-2026-23813) effectively controls the forwarding behavior of the switch: routing tables, ACLs, VLAN membership, spanning tree priorities, and port configurations are all within reach. The REST API surface that makes AOS-CX attractive for network automation is the same surface that an attacker with admin credentials can drive arbitrarily.

That point deserves specific attention for organizations running automation tooling against their AOS-CX fleet. Frameworks and products that use the AOS-CX REST API — including Ansible's arubanetworks.aoscx collection, HPE's own Network Analytics Engine (NAE), and Terraform provider integrations — authenticate against the same web management interface that CVE-2026-23813 targets. An attacker who resets the admin password and modifies device configuration through the API can introduce changes that downstream automation tools subsequently read as authoritative state, potentially propagating a malicious configuration to other devices in the fabric. If your environment uses any of these tools, the management interface is not just a console for humans — it is a programmatic control plane, and its exposure surface is proportionally larger.

The Companion CVEs: A Wider Exposure

CVE-2026-23813 is the lead issue in a five-CVE advisory, but the others deserve individual attention rather than being treated as afterthoughts.

CVE-2026-23814 is an authenticated command injection vulnerability in the AOS-CX CLI, rated High at CVSS 8.8. It allows a low-privilege authenticated attacker to inject malicious commands through crafted parameters to a CLI command, resulting in arbitrary code execution. The low-privilege threshold is the critical detail here: this is not limited to administrators.

CVE-2026-23815 is also a command injection flaw, but it targets a custom binary used in the AOS-CX CLI for an administrative command. Rated High at CVSS 7.2, it requires high-privilege authenticated access, making it a post-exploitation tool rather than an initial access vector.

CVE-2026-23816 is a third authenticated OS command injection vulnerability in an administrative AOS-CX CLI command. Also rated High at CVSS 7.2, it allows a high-privilege attacker to execute arbitrary commands directly on the underlying operating system, bypassing the normal boundaries between the CLI and the host system.

CVE-2026-23817 is rated Medium at CVSS 6.5 and represents a different class of risk. It is an unauthenticated open redirect vulnerability in the web management interface that allows a remote, unauthenticated attacker to redirect users to arbitrary URLs via crafted requests. In practice, this enables phishing attacks targeting network administrators: an attacker who can redirect an admin's browser from the switch management console to a credential-harvesting page gains access through a social engineering channel rather than a technical one.

Affected Versions and Hardware

The vulnerability spans four major AOS-CX software branches. Organizations should check their installed version against each of the following thresholds.

AOS-CX 10.10.xxxx  — All versions at or below 10.10.1170 (includes end-of-support builds)
AOS-CX 10.13.xxxx  — All versions at or below 10.13.1160
AOS-CX 10.16.xxxx  — All versions at or below 10.16.1020
AOS-CX 10.17.xxxx  — All versions at or below 10.17.0001

The India CERT advisory (CIVN-2026-0137) confirmed the affected version boundaries above, noting that the flaw is present in multiple major and minor releases including some that have reached end-of-support status. For organizations running end-of-support AOS-CX versions, patching may require a platform upgrade rather than a simple software update.

How to check your installed version

If you are unsure which AOS-CX branch and build your switches are running, the fastest check is a single CLI command. From a console or SSH session on any affected switch:

show version

The output will display the software version string in the format AOS-CX XX.XX.XXXX. Match the first two octets against the four vulnerable branches listed above, then compare the full build number to the patched thresholds. If you manage a large switch estate, the AOS-CX REST API can be queried programmatically across devices using a GET request to /rest/v10.08/system and inspecting the software_version field — though that approach only applies to switches where the management interface is reachable and a valid session can be established.

The hardware platforms confirmed as affected by HPE's advisory include the CX 4100i, CX 6000, CX 6100, CX 6200, CX 6200F, CX 6300, CX 6400, CX 8320, CX 8325, CX 8360, CX 8400, CX 9300, and CX 10000 series switches. This range covers access-layer devices through high-capacity spine and data center switches, meaning the exposure spans virtually every network tier where AOS-CX is deployed. The inclusion of the CX 6200F — a fiber-uplink variant commonly used in high-density campus aggregation — and the CX 8400 modular chassis, a core-layer platform designed for large enterprise and data center spine roles, underscores how broadly the exposure reaches: these are not edge curiosities but central-layer devices where a compromise can affect traffic moving between entire building floors or data hall rows.

Patches and Mitigation

HPE released patched software versions alongside the March 11, 2026 advisory. The fixed versions for each affected branch are as follows.

AOS-CX 10.10.xxxx  — Upgrade to 10.10.1180 or later
AOS-CX 10.13.xxxx  — Upgrade to 10.13.1161 or later
AOS-CX 10.16.xxxx  — Upgrade to 10.16.1030 or later
AOS-CX 10.17.xxxx  — Upgrade to 10.17.1001 or later

For organizations that cannot apply patches immediately, HPE recommends a layered mitigation strategy. The primary control is restricting network access to the web management interface. This means isolating the management interface on a dedicated VLAN that is inaccessible from general-purpose network segments, enforcing access control lists (ACLs) to ensure that only explicitly trusted hosts can reach the HTTPS and REST API endpoints, and disabling the HTTP and HTTPS management interfaces on Switched Virtual Interfaces (SVIs) and routed ports where the web management plane is not operationally necessary.

HPE also advises enabling comprehensive accounting, logging, and monitoring of management interfaces. While logging alone cannot prevent exploitation, it provides the detection capability needed to identify unauthorized password reset activity and respond before an attacker consolidates their position. Organizations with SIEM infrastructure should confirm that AOS-CX management interface logs are ingested and that alerts exist for unexpected authentication events, password change events, and configuration modifications.

What to Look For — and What to Do If You Find It

Enabling logging is not useful if no one knows what a successful exploitation attempt looks like in those logs. On AOS-CX switches with management interface logging configured, an unauthenticated password reset would appear as a password change event for the admin account with no corresponding preceding login event from that source address. The absence of an authenticated session preceding the credential change is the signal. Depending on your logging configuration, look for syslog messages referencing AAA or MGMT subsystems with change or update events tied to the admin user, particularly if the source IP is not a recognized management host.

Concurrently, any switch that was reachable from an untrusted segment during the window between March 11, 2026 (public advisory date) and your patch or ACL deployment should be treated as potentially compromised until confirmed otherwise. Signs of post-exploitation activity include routing table changes you did not authorize, VLAN membership modifications, new user accounts or SSH keys in the device configuration, unexpected outbound REST API calls in proxy or firewall logs, and locked-out legitimate administrator access.

If you identify a switch that shows indicators of compromise, the remediation path is not simply applying the patch. A compromised switch may have a modified configuration that persists through a software upgrade. The correct sequence is: isolate the device from the network, restore the configuration from a known-good backup taken before the exposure window, upgrade to the patched AOS-CX build, and re-commission the device. If no pre-exposure configuration backup exists, treat the device as requiring a full rebuild from baseline. This is an argument for maintaining regular automated configuration backups using AOS-CX's built-in checkpoint facility or an external network configuration management tool — a practice that helps in any failure scenario but becomes essential when compromise is suspected.

For organizations running end-of-support AOS-CX branches where no patch is available, the interim situation is more constrained. The ACL and VLAN isolation mitigations described in the Patches and Mitigation section remain the primary controls available, but they are compensating controls rather than fixes. HPE's support organization should be contacted to understand whether an emergency patch or upgrade path exists for those branches, and the risk should be formally documented and accepted at an appropriate level within the organization until a longer-term resolution is reached.

HPE's Broader Authentication Problem

CVE-2026-23813 does not exist in isolation within HPE's recent security history. In July 2025, HPE disclosed hardcoded credentials in Aruba Instant On Wi-Fi access points under CVE-2025-37103, also rated critical at CVSS 9.8. That flaw allowed anyone with knowledge of the hardcoded credentials to bypass normal device authentication on devices running firmware version 3.2.0.1 and below, affecting small and medium business wireless deployments. One month before that, HPE patched eight vulnerabilities in its StoreOnce backup and deduplication platform, including another critical-severity authentication bypass and three remote code execution flaws.

In January 2026, CISA added a maximum-severity HPE OneView vulnerability to its Known Exploited Vulnerabilities catalog, confirming active exploitation in the wild. Taken together, these disclosures point to a pattern of authentication and access control weaknesses appearing across HPE's product lines. Each flaw is discrete and addressed by its own patch, but the frequency across different product categories over a twelve-month window warrants attention from organizations that rely heavily on HPE infrastructure. For context on how authentication bypass vulnerabilities in network devices have been weaponized in the wild, the CVE-2024-55591 FortiGate incident is instructive. For context on how pre-authentication remote code execution flaws in enterprise infrastructure products have played out in recent months, the BeyondTrust CVE-2026-1731 incident offers a direct parallel.

Filipek's observation to CSO Online — that network device vulnerabilities have grown more prevalent as enterprise environments become increasingly interconnected — reflects a broader industry-wide recognition that network infrastructure must now be treated as a primary attack surface, not a perimeter assumption.

The MITRE ATT&CK framework entries most relevant to CVE-2026-23813 are T1078 (Valid Accounts) — because resetting and then using admin credentials constitutes abuse of valid accounts from the defender's perspective — and T1190 (Exploit Public-Facing Application), which describes the initial access technique involved. Organizations using ATT&CK-aligned detection frameworks should review coverage for both techniques in the context of network device management interfaces.

Historically, high-severity vulnerabilities in network management interfaces attract threat actor attention once exploit code becomes publicly available. Nation-state actors and ransomware operators alike have demonstrated consistent interest in network infrastructure as a means of establishing persistent footholds, enabling lateral movement, and disrupting business continuity. The broad deployment of Aruba CX-series switches in enterprise and critical sector environments means that a working exploit for CVE-2026-23813 would have a large potential target pool. No such exploit has been observed or confirmed as of this writing, but the trajectory of similar disclosures suggests the window is not indefinite.

Why This Vulnerability Class Is Structurally Dangerous

A password reset bypass in a web management interface sounds like a bounded, specific problem. It is not. Understanding why requires looking at what the management plane of a modern switch is — and what it is not.

In legacy switch operating systems, the management plane was largely a configuration terminal. It let administrators issue commands, but the separation between configuration state and forwarding state was implicit and often fragile. AOS-CX is different by design: it uses an OVSDB-backed architecture where the management plane is a write interface to a structured database that the forwarding engine treats as authoritative. This is what makes AOS-CX powerful for automation. It is also what makes a management plane compromise categorically more dangerous than in older architectures.

When an attacker resets the admin password on an AOS-CX switch, they do not just gain a console session. They gain write access to the device's entire operational state as a persistent, authenticated principal. Every subsequent action they take — modifying routing tables, changing VLAN assignments, inserting ACL rules, altering spanning tree priority, enabling port mirroring — is committed to the state database and reflected in the data plane immediately. From a detection standpoint, this looks like authorized administrative activity, because from the switch's perspective, it is. The attacker is not injecting packets into the forwarding plane from outside; they are using the device's own management API to reprogram how it behaves. Distinguishing that from legitimate administrative change requires log analysis and behavioral baselines, not simple anomaly detection on traffic flows.

This matters even more in environments that have adopted infrastructure-as-code practices for network management. When Ansible playbooks, Terraform providers, or NAE analytics engines pull configuration state from these devices over the REST API, they do so against what the device reports as current authoritative state. An attacker who introduces malicious configuration through an authenticated session does not need to touch those automation tools directly — the tools will observe the modified state and treat it as ground truth. In a continuous reconciliation model, that could mean automation workflows actively preserving attacker-introduced configurations across subsequent runs, because the tooling sees no delta between desired state and actual state.

That feedback loop — where legitimate automation amplifies an attacker's persistence — is not unique to CVE-2026-23813, but this vulnerability provides a particularly clean entry point for establishing it.

Going Beyond Standard Mitigation

The guidance in the Patches and Mitigation section — patch promptly, restrict management access via ACLs, isolate on a dedicated VLAN, enable logging — represents correct and necessary baseline practice. But "necessary baseline" is not the same as sufficient architecture. Organizations that want durable protection against this class of vulnerability, not just a specific fix for CVE-2026-23813, need to address the structural conditions that make management plane bypasses broadly dangerous.

Out-of-Band Management Network Architecture

Placing the web management interface on an in-band VLAN — even a restricted one — means management traffic shares physical infrastructure with production traffic. An attacker who has already established a foothold elsewhere in the network can potentially reach that VLAN through a misconfiguration, a trunking error, or a VLAN hopping technique. A true out-of-band management network physically separates management traffic onto dedicated hardware: a separate management switch fabric, dedicated management NICs on servers, and management-only uplinks on the devices being managed. This architecture means that exploiting a vulnerability like CVE-2026-23813 requires first compromising the out-of-band network, which has a completely separate attack surface and authentication boundary from the production network. For organizations that have not implemented physical out-of-band management, this vulnerability is an argument to accelerate that investment — not as a response to this specific CVE, but because the management plane of every network device is now an attack surface that adversaries know how to target.

Configuration Integrity Monitoring

Patch management and access control prevent exploitation. Configuration integrity monitoring detects it when prevention fails. The goal is to establish a continuous comparison between known-good device configuration state and current device configuration state, generating alerts when unauthorized changes are detected. AOS-CX exposes its full configuration over the REST API, which makes programmatic integrity monitoring feasible without requiring physical console access. Tools like Oxidized and Rancid can be configured to poll device configurations on a scheduled basis and commit snapshots to a version-controlled repository; a diff between successive commits that does not correspond to a tracked change request is an indicator of unauthorized modification. More sophisticated approaches use streaming telemetry — AOS-CX supports gNMI/gRPC-based telemetry — to receive real-time state change events from devices and correlate them against a change management record. An OVSDB state change that has no corresponding approved change ticket should generate an immediate alert, not a nightly report. Organizations that are serious about detecting post-exploitation activity need to treat configuration state as a security artifact with the same monitoring rigor applied to endpoint process behavior.

Zero-Trust Management Plane Design

ACLs that limit management access to trusted hosts represent a perimeter model: the boundary is defined by network address, and anything inside the boundary is assumed authorized. Zero-trust applied to the management plane eliminates that assumption. Under a zero-trust management architecture, every management session requires mutual authentication — not just the device authenticating the administrator, but the administrator's client authenticating to the device using a certificate or hardware credential that cannot be replayed from a different host. AOS-CX supports SSH certificate authentication and can be configured to require client certificates for REST API access. Combined with an internal certificate authority and short-lived certificate issuance, this model means that even if an attacker can reach the management interface network address, they cannot establish an authenticated session without a valid, unexpired certificate bound to an approved identity. The authentication bypass in CVE-2026-23813 exploits a flaw in session token validation — it does not bypass mutual TLS certificate verification. Organizations that have deployed mutual TLS for management plane access are therefore not protected from the bypass as patched, but are in a substantially better position against future management plane authentication flaws in this class.

Privileged Access Workstations and Jump Host Enforcement

Even with ACLs in place, the attack surface of the management plane is bounded by which hosts are trusted. If the set of trusted hosts includes general-purpose administrator workstations — machines that are also used for email, web browsing, and running productivity software — then compromising any of those workstations provides a launching point for management plane attacks from a trusted address. Privileged access workstations (PAWs) address this by dedicating specific hardened endpoints exclusively to administrative tasks, with no general internet access, no email client, and no software that is not required for device management. Management access to network infrastructure is permitted only from PAWs; PAWs are not permitted to access general network resources. This reduces the attack surface for lateral movement into the management plane from a compromised user endpoint. In environments where physical PAWs are not practical, jump hosts or bastion servers in the management network fulfill a similar role when properly hardened and monitored.

Automated Firmware and Lifecycle Governance

One of the more uncomfortable findings in this advisory is that AOS-CX 10.10.xxxx — an end-of-support branch — is among the affected versions. End-of-support software remaining in production is not an operational anomaly; it is an extremely common condition in enterprise network infrastructure, where hardware replacement cycles and risk aversion often result in devices running software versions years past vendor support dates. CVE-2026-23813 is a concrete, immediate cost of that deferral.

The solution is not simply "patch faster," because in environments with hundreds or thousands of network devices, patching is not a manual task that speed alone addresses. It requires automated firmware inventory, automated identification of devices running vulnerable or end-of-support versions, and integration with change management workflows that can schedule and execute upgrades at scale. Network device management platforms — including HPE's own Aruba Central, as well as third-party tools like NetBox for inventory and Batfish for configuration analysis — can provide the inventory and validation layer. Coupling that inventory to a defined end-of-support policy that triggers automated upgrade planning when a version approaches its support sunset removes the gap between "we know this is a problem" and "someone has to schedule it."

Threat-Informed Red Team Exercises for Network Infrastructure

Network device management interfaces are rarely included in the scope of red team engagements or penetration tests. The default assumption is that network devices are out of scope because they are "infrastructure," not "applications." CVE-2026-23813 illustrates exactly why that assumption is wrong. A red team exercise scoped to include management plane access against production switches — under controlled conditions, with network operations team coordination — would have revealed the exposure surface that this vulnerability targets: web management interfaces accessible from segments where they should not be reachable. Organizations that have not evaluated their management plane exposure through adversarial testing should use this advisory as a prompt to expand scope on future engagements. The goal is not to confirm whether CVE-2026-23813 is exploitable on specific devices; it is to identify the architectural conditions that made the exposure possible, so those conditions can be corrected independently of any specific CVE.

Key Takeaways

1. Patch now, not later: Fixed versions are available for all four affected AOS-CX branches. The update versions are 10.10.1180, 10.13.1161, 10.16.1030, and 10.17.1001. Apply whichever corresponds to your installed branch as soon as change management allows.
2. Restrict management interface access immediately: If patching cannot happen today, isolate the web management interface on a dedicated VLAN, enforce ACLs to limit access to trusted hosts only, and disable the interface on SVIs and routed ports where it is not needed. This is the single most effective interim control available.
3. Audit all affected hardware: The vulnerability spans CX 4100i, CX 6000, CX 6100, CX 6200, CX 6200F, CX 6300, CX 6400, CX 8320, CX 8325, CX 8360, CX 8400, CX 9300, and CX 10000 series switches. Enumerate all affected devices in your environment before assuming coverage is complete. Use show version on each device to confirm the installed build.
4. Enable management interface logging and connect it to your SIEM: Detection is not prevention, but it limits attacker dwell time. Confirm that authentication events, password changes, and configuration modifications from AOS-CX management interfaces are captured and alerted on. A password change for the admin account with no preceding authenticated session from that source is the indicator to watch for.
5. Treat CVE-2026-23814 as a companion threat: The CVSS 8.8 command injection flaw can be chained with CVE-2026-23813 to extend a compromise from the network management plane to the underlying operating system. Both should be patched together, and mitigation planning should account for the compound scenario.
6. Address end-of-support branches explicitly: Switches on 10.10.xxxx builds that have passed end-of-support status may not have a straightforward software update path. Contact HPE support to understand your options and formally document the accepted risk until an upgrade path is executed.
7. Maintain configuration backups: If a switch is later confirmed as compromised, applying the patch alone is insufficient — a modified configuration persists through a software upgrade. Regular automated configuration snapshots using AOS-CX checkpoints or an external network configuration management tool make recovery from any compromise event substantially faster and more reliable.

The absence of confirmed exploitation as of the advisory date is a temporary condition, not a safety guarantee. A CVSS 9.8 vulnerability requiring no credentials, no user interaction, and no special conditions will attract scrutiny from researchers and adversaries alike following public disclosure. The IONIX research team publicly noted it is actively tracking exploitation attempts for CVE-2026-23813 — a signal that at least some external visibility into attack surface exposure is already under way. Organizations running affected AOS-CX versions should treat the current window as an opportunity to remediate before that equation changes.