How do you patch or mitigate CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection)?

What patching CVE-2025-66644 should look like in practice

Start by locating every Array Networks ArrayOS AG instance, including devices that sit in a DMZ, are remotely managed, or were originally deployed as temporary infrastructure and later forgotten. Because the issue is command injection, the remediation decision is not just “patch or not”, but whether the exposed management surface can be trusted until the vendor update or mitigation is in place. For broader edge-device triage, see Edge Device Security Guide.

If the vendor security update or documented mitigation is available, apply it first and verify that the management interface is no longer reachable from untrusted networks. When the platform cannot be fixed quickly, the safe fallback is to remove internet exposure, restrict administrative access to trusted paths, or retire the product if no workable mitigation exists. Vulnerability Management Guide is useful for handling the prioritisation and exception step that should follow that decision.

Because CISA ties this flaw to required mitigation and, where applicable, discontinuation of use, the operational question is whether the device can remain in service without being exposed to arbitrary command execution. If the answer is no, treat exposure reduction as part of the fix, not a temporary workaround to be deferred. The same logic applies to other internet-facing appliances with management planes that should never be reachable from the public network.

Why this flaw is especially dangerous on an edge appliance

Command injection on an appliance is high impact because the attacker is not trying to break one user account, they are trying to get the device itself to execute commands. That can turn a perimeter box into a foothold for credential theft, configuration tampering, traffic redirection, or lateral movement into internal systems. For the wider class of web and appliance injection issues, Web Application Attacks Guide covers the attack pattern that makes this kind of flaw so reusable.

In practice, the exposure is usually worst when the device has an administrative interface on the public internet, when default management paths are left open, or when the appliance is treated as “network equipment” rather than a security-sensitive host. The risk is not limited to the immediate box, because compromise of the management layer can affect VPN access, routing, logging, and trust boundaries that other systems depend on.

How to confirm you are clean after remediation

After patching or mitigation, confirm that the vulnerable code path is no longer reachable and that the device is no longer accepting unauthenticated or weakly protected management traffic from outside approved administration networks. Review logs for suspicious requests around the exposure window, because command-injection flaws are often probed before successful exploitation. If the appliance handled secrets, sessions, or admin credentials, assume those may need to be rotated as a precaution.

Do not stop at the version check alone. Validate that the fix matches the vendor advisory for your exact model and deployment pattern, and that compensating controls such as ACLs, VPN-only administration, or isolation are actually enforced. If you cannot prove the exposure has been closed, the safer conclusion is that the risk still exists.

Risk and Threat Considerations

The main risk is that a publicly reachable appliance becomes a remote command execution entry point for anyone who can send crafted requests. On edge devices, that often creates a high-value path into administrative functions, credentials, and internal traffic control, so the blast radius can be larger than the product itself.

Failure mechanism: An attacker abuses command injection to make the appliance execute operating-system commands, then uses that execution to alter configuration, harvest secrets, or pivot deeper into the environment.

Impact: The device can be repurposed as a staging point for persistence, internal reconnaissance, traffic manipulation, or broader compromise of systems that trust the appliance.

Practitioner Guidance

What to prioritise: Treat internet exposure of the management plane as the urgent issue. If the device cannot be patched immediately, isolate it first, then decide whether it can remain in service under compensating controls or must be removed.

What to verify: Confirm the exact ArrayOS AG deployment, the vendor remediation path, and the external reachability of every administrative interface. A patch that is installed but still exposed to the public internet is not a complete mitigation.

Decision rule: If you cannot apply the vendor fix and cannot credibly contain the interface, discontinue use of the product rather than leaving a vulnerable perimeter device in place.

Practitioner takeaway: For edge appliances, the right question is not only whether a patch exists, but whether you can also eliminate exploitable exposure while you deploy it.

Related resources from NHI Mgmt Group

• Is CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection) being exploited in the wild?
• CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection)
• How do you patch or mitigate CVE-2023-28461 (Array Networks AG and vxAG ArrayOS Missing Authentication for Critical Function)?
• How do you patch or mitigate CVE-2024-9474 (Palo Alto Networks PAN-OS Management Interface OS Command Injection)?