How do you patch or mitigate CVE-2023-28461 (Array Networks AG and vxAG ArrayOS Missing Authentication for Critical Function)?

CISA’s required action for CVE-2023-28461 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Array Networks AG/vxAG ArrayOS in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.

What “patch or mitigate” means for this CVE in practice

This is a missing-authentication flaw in an internet-reachable appliance class, so the first decision is exposure control, not just patch logistics. Treat every deployed Array Networks AG or vxAG ArrayOS instance as a candidate for immediate remediation, and if you cannot apply the vendor fix or an approved mitigation, remove the service from external reach until it can be brought into a known-safe state.

The practical workflow is to inventory the affected product everywhere it exists, confirm whether the vulnerable management or service path is exposed, and then apply the vendor’s security update or documented workaround. If the vendor guidance cannot be executed in your environment, the fallback is to take the product out of service rather than leave an unauthenticated critical function reachable on the network.

For patch planning, use a vulnerability-management process that starts with asset identification and ends with verification, not just installation. Vulnerability Management Guide is the right internal reference point for prioritisation, exception handling, and remediation verification when a KEV-listed issue needs fast operational handling.

When the device is part of a perimeter access path, the mitigation decision should also account for whether the appliance can be safely isolated while business traffic is re-routed or access is temporarily constrained. Edge Device Security Guide covers the operational reality of exposed gateways and other internet-facing appliances that often cannot be left in a partially trusted state.

How to confirm you are actually exposed

Start by identifying every Array Networks AG and vxAG ArrayOS instance in production, test, disaster recovery, and vendor-managed environments. Exposure is not just “is the software installed?” but “is the vulnerable function reachable from a network path that an attacker could use before authentication is enforced?”

Then verify whether the instance is running the vendor-fixed build or an approved mitigation state. If you are unsure, assume exposure until the vendor advisory or your own validation confirms otherwise, because appliances like this are often overlooked in standard endpoint tooling and can sit outside normal patch cadences.

Do not stop at the internet edge. Internal access paths, VPNs, partner connections, and management planes can still make a vulnerable appliance reachable even when direct public exposure is reduced. The question is whether the unauthenticated critical function can be invoked at all, not whether the service is neatly segmented on paper.

For fast prioritisation, align the response with the fact that this is a known exploited vulnerability and use authoritative records for the exact product scope and required action. CISA Known Exploited Vulnerabilities Catalog tells you whether a listed issue must be treated as an urgent remediation item, while NIST National Vulnerability Database helps you tie the CVE record to the product entry your scanners and CMDB should be using.

For authoritative identifier hygiene and record matching, the official CVE Program record is the source of truth for the vulnerability identity you should use in tickets, change records, and exceptions.

Mitigation paths when patching is delayed

If you cannot patch immediately, use the vendor’s documented mitigations exactly as written and verify that they materially reduce reachability of the vulnerable function. For appliance issues, that often means tightening exposure, disabling the affected interface or feature where supported, restricting source networks, or moving the device behind stronger access controls until the permanent fix is applied.

If a documented mitigation is not available or cannot be applied safely, discontinuing use is the correct decision. In practical terms that means taking the instance out of service, replacing it, or placing it in a non-production state that does not expose the vulnerable function to real traffic.

Do not let a compensating control become an excuse to defer remediation indefinitely. A temporary network restriction is only a valid bridge if you can show it actually removes attacker reach to the vulnerable path and is being tracked to a final fix date.

When there is operational pressure to keep the appliance live, Edge Device Security Guide is useful for framing the fallback options around appliance hardening, management-plane exposure, and end-of-life decisions rather than treating the issue as a routine software patch.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE-2023-28461 needs rapid identification, prioritisation, and remediation tracking.
Recommendation — Prioritise, remediate, and verify the vulnerable appliance under a continuous vulnerability management process.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	The subject is a live vulnerability remediation workflow for an exploited product.
Recommendation — Track, prioritise, and remediate the CVE through an established vulnerability management process.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue requires applying vendor fixes or approved mitigations and verifying completion.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation depends on finding all instances and validating their state.
Recommendation — Apply the vendor fix or approved mitigation and verify the appliance is no longer vulnerable. Scan and inventory the product to confirm exposure and remediation status.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	The CVE is a technical vulnerability requiring timely handling and exception control.
Recommendation — Manage the vulnerability through documented remediation, mitigation, and exception review.

Practitioner Guidance

What to prioritise: Treat internet-reachable instances first, then any system that brokers remote access or administrative entry. If the appliance can be touched by unauthenticated traffic, patch or isolate it before spending time on lower-risk internal deployments.

What to verify: Confirm the device is either on the vendor-fixed release or covered by a mitigation you can defend operationally. Also verify that the change actually removes the vulnerable path, not just the banner or the management login page.

Escalation / exception: If the product cannot be patched, cannot be mitigated, or remains externally reachable after attempted remediation, escalate it as a service-risk issue rather than a routine vulnerability ticket. The right exception outcome is removal, replacement, or disconnection from exposure.

Practitioner takeaway: For a KEV-listed appliance flaw with missing authentication, the safe answer is binary, fix it quickly or stop exposing it; anything in between should be treated as temporary and actively measured.