Yes. CISA added CVE-2025-66644 to its Known Exploited Vulnerabilities catalogue on 8 December 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Array Networks ArrayOS AG contains an OS command injection vulnerability that could allow an attacker to execute arbitrary commands. Any organisation running the affected product should treat remediation as urgent.
Why active exploitation changes the response
A KEV listing means the vulnerability has crossed from theoretical exposure into a known exploitation problem. For teams running ArrayOS AG, that changes the question from “Is this worth tracking?” to “Are we exposed, and how quickly can we remove the attack path?” The practical priority is confirming whether the product is internet-facing, internally reachable, or embedded in a critical network path.
Because this is an OS command injection flaw, the security concern is not just service disruption. Successful exploitation can give an attacker direct command execution on the appliance, which makes the device a foothold for credential theft, network pivoting, configuration tampering, or service interruption. Guidance for edge-device hardening and exposed management interfaces is especially relevant here, because those are the conditions that often turn a single vulnerability into broad reachability across the environment, as covered in the Edge Device Security Guide.
For prioritisation, treat KEV status as the deciding factor rather than waiting for a local proof-of-exploit. The CISA Known Exploited Vulnerabilities Catalog and the vendor advisory are the right sources for remediation timing and product-specific instructions, but the operational implication is immediate triage, not deferred backlog handling.
How to confirm exposure and contain the blast radius
Start by identifying every instance of ArrayOS AG, including appliances that may be managed by another team or hidden behind a load balancer, VPN, or administrative subnet. If you cannot prove whether the platform is present, you cannot prove whether you are safe. Then determine whether the management plane is reachable from untrusted networks, because exposed admin surfaces are usually the shortest path to exploitation.
If the device is exposed, segment it aggressively and restrict administrative access to known management sources only. Also review logging on the appliance and on adjacent systems for abnormal command execution, unexpected configuration changes, new user creation, outbound connections, or signs that the device was used to reach other hosts. Where the product sits on a trust boundary, assume compromise of the appliance may create downstream risk even if the service itself looks healthy.
When patching must wait, containment should be the temporary control, not the end state. Reduce exposure, block unnecessary management access, and monitor for any behaviour that suggests the appliance has already been used as an initial access point.
What recovery looks like after a likely exploit
When command injection is involved, post-exploitation review matters as much as patching. The attacker may have used the appliance to retrieve stored secrets, alter routing or access rules, or establish persistence through configuration changes. If the device stores credentials, API keys, certificates, or session material, rotate anything that could have been visible or reused from the appliance context.
Recovery should also include a targeted compromise assessment of systems that depended on the appliance for authentication, routing, or administrative access. If evidence suggests the box was touched, validate whether its logs are complete enough to support the investigation. If not, rely on adjacent telemetry such as firewall logs, identity logs, proxy logs, and endpoint detections to reconstruct what happened around the exploitation window.
For teams handling internet-facing appliances, this is the same class of urgency seen in other exploited edge-device incidents, where the real risk is often the post-initial-access path rather than the first command itself. The point is not merely to close the CVE, but to verify that the appliance was not turned into a durable access path.
Risk and Threat Considerations
Actively exploited command injection on an edge appliance creates two risks at once: direct compromise of the device and secondary compromise of whatever the device can reach. Once an attacker can execute commands, the appliance can become a staging point for pivoting, reconnaissance, or credential capture.
Failure mechanism: The flaw allows attacker-supplied input to be executed as operating system commands, which can bypass intended administrative controls and turn a management or service interface into arbitrary code execution on the appliance.
Impact: Attackers may gain persistent foothold, alter device behaviour, steal credentials or tokens present on the system, or use the appliance to move deeper into the environment.
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 governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed exploitation requires urgent vulnerability prioritization and remediation tracking. |
| Recommendation — Prioritise and remediate the exposed ArrayOS AG systems immediately. | ||
| NIST CSF 2.0 | PR.PS-05 — Protective Technology | Edge appliance exposure is reduced by restricting and hardening the management surface. |
| DE.CM-01 — Networks and Network Services Monitored | Exploit detection depends on monitoring network and service behaviour around the appliance. | |
| Recommendation — Restrict and harden appliance management access paths. Monitor appliance and adjacent network activity for exploitation indicators. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | An actively exploited CVE demands inventory, exposure validation, and fast remediation tracking. |
| SI-2 — Flaw Remediation | This CVE requires prompt flaw remediation after confirmation of exposure. | |
| Recommendation — Track exposed ArrayOS AG instances and drive rapid remediation. Apply the vendor fix or mitigation as soon as exposure is confirmed. | ||
Practitioner Guidance
What to prioritise: Confirm whether ArrayOS AG is deployed anywhere in the estate, then prioritise devices that are internet-facing or reachable from broad internal networks. Those are the instances most likely to be exploited first and the hardest to defend with compensating controls alone.
What to verify: Check whether you have evidence of command execution, configuration drift, new administrative accounts, unusual outbound traffic, or missing logs around the exposure window. If any of those are present, treat the issue as potential compromise, not just vulnerability management.
Decision rule: If the appliance can still be reached from untrusted networks and cannot be patched immediately, isolate it first and validate downstream dependencies second. If it already stores or brokers sensitive credentials, rotate those secrets before assuming the device was clean.
Practitioner takeaway: For KEV-listed command injection on an edge appliance, speed matters, but exposure mapping and compromise checks matter just as much, because the device may already have served as the attacker’s foothold.
Related resources from NHI Mgmt Group
- CVE-2025-66644 (Array Networks ArrayOS AG OS Command Injection)
- Is CVE-2025-4428 (Ivanti Endpoint Manager Mobile (EPMM) Code Injection) being exploited in the wild?
- CVE-2023-28461 (Array Networks AG and vxAG ArrayOS Missing Authentication for Critical Function)
- CVE-2024-9474 (Palo Alto Networks PAN-OS Management Interface OS Command Injection)