Is CVE-2023-28461 (Array Networks AG and vxAG ArrayOS Missing Authentication for Critical Function) being exploited in the wild?

What makes CVE-2023-28461 exploitable in practice?

This is not just a theoretical flaw. The issue is missing authentication for a critical function on an internet-facing SSL VPN gateway, which means the exposure path is directly reachable to an outside attacker if the device is accessible. The meaningful question for defenders is whether the gateway is exposed, whether it was already reachable from the internet, and whether logs show requests to the vulnerable function before CISA’s KEV listing.

Because the vulnerability can enable both file read and code execution on the gateway, the impact is broader than a simple login bypass. Once an attacker can interact with the appliance unauthenticated, they may be able to move from initial access into payload delivery, configuration theft, or pivoting into adjacent systems that trust the VPN boundary.

For organisations triaging this class of edge-device issue, the Edge Device Security Guide is the right internal reference point because it focuses on exposed gateways, appliance credentials, management exposure, and the logging needed to see abuse early.

How should defenders confirm exposure and contain the gateway?

First confirm whether any Array Networks AG or vxAG ArrayOS instance is internet-facing and whether it is still within your approved asset inventory. For edge devices, exposure is often the issue, not just patch status. If the device is in scope, treat the gateway as a high-priority external entry point and check whether remote administration, VPN portals, or other management surfaces are reachable without additional network restriction.

If the device is exposed, containment should focus on reducing reachability while remediation is underway. That may mean restricting source IPs, placing the interface behind a temporary access control, disabling unnecessary services, or isolating the appliance from sensitive internal segments until the vendor fix or approved mitigation is in place.

For exploitability triage, CISA KEV is the authoritative signal that the vulnerability is being used in the wild, and the CISA Known Exploited Vulnerabilities Catalog should be checked alongside the vendor advisory for current remediation steps.

What should you check for after exposure or suspected abuse?

If the gateway may have been reachable before containment, look for signs of compromise rather than assuming patching alone is enough. Review authentication, admin, and traffic logs for unusual requests to the appliance, unexpected configuration changes, unfamiliar file access patterns, and any evidence that the SSL VPN gateway issued commands or fetched external content it should not have accessed. If code execution is suspected, treat the appliance as a potential launch point for lateral movement.

Because the flaw can permit file reading, assume that sensitive local material may have been exposed. That makes credential review material: rotate any secrets, keys, or service credentials stored on or reachable from the appliance if compromise is plausible, and invalidate sessions or tokens that may have been captured through the gateway.

The best operational comparison point is a zero-day style emergency workflow, and the Zero-Day and Exploited Vulnerabilities Guide provides a useful model for emergency mitigation, compromise assessment, and post-patch hunting.

Risk and Threat Considerations

SSL VPN appliances sit at a privileged boundary, so a remotely reachable authentication failure can become a direct path into trusted network space. When a gateway is already exposed to the internet, the main risk is not only initial compromise but also credential theft, session abuse, and follow-on access to internal resources that normally depend on the gateway’s trust relationship.

Failure mechanism: An unauthenticated requester can hit a critical function on the gateway, then use file read or code execution capability to extract local data, implant code, or establish persistence before defenders notice.

Impact: The result can include full gateway compromise, exposure of configuration or secrets, and a downstream foothold for lateral movement into internal systems, especially where the VPN appliance is treated as a trusted access broker.

Practitioner Guidance

What to prioritise: Treat any exposed Array Networks AG or vxAG ArrayOS instance as an urgent boundary risk, not a routine patch ticket. Prioritise external reachability, log review, and containment first, then remediation and hunting.

What to verify: Verify whether the device was internet-facing before CISA’s KEV listing date, whether the vulnerable function was accessible, and whether logs or configuration drift suggest pre-existing compromise. If you cannot confirm the gateway was unreachable, assume the blast radius is larger than the appliance itself.

Decision rule: If the gateway may have been exposed, rotate any material secrets or sessions that could have been read from the device before you declare the issue closed. Patching without credential review leaves a plausible post-compromise path intact.

Practitioner takeaway: For an exploited edge-device CVE, exposure and compromise assessment matter as much as patching, because the appliance may already have been used to obtain secrets or pivot deeper into the network.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2023-28461 (Array Networks AG and vxAG ArrayOS Missing Authentication for Critical Function)?
• CVE-2023-28461 (Array Networks AG and vxAG ArrayOS Missing Authentication for Critical Function)
• Is CVE-2025-32433 (Erlang Erlang/OTP SSH Server Missing Authentication for Critical Function) being exploited in the wild?
• Is CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection) being exploited in the wild?