Is CVE-2022-24990 (TerraMaster OS Remote Command Execution) being exploited in the wild?

What active exploitation means for this TerraMaster OS flaw

When a vulnerability lands in CISA’s Known Exploited Vulnerabilities catalogue, the practical question is no longer whether it is theoretically dangerous, but whether exposed systems are still reachable and whether attackers may already be using it. For TerraMaster OS, that means treating any internet-facing or unsegmented appliance as a priority exposure, not a routine patch item.

The key operational issue is unauthenticated remote command execution. If an attacker can send commands without valid credentials, they do not need prior access, valid sessions, or insider help. That changes the response from ordinary maintenance to emergency containment, because the flaw can be used directly for foothold creation, reconnaissance, payload staging, or follow-on access.

For a broader response pattern, NHI and asset teams should treat actively exploited flaws as a separate class from ordinary vulnerabilities and use a dedicated triage path such as Zero-Day and Exploited Vulnerabilities Guide when deciding what to isolate, patch, and verify first.

How to confirm exposure and shorten the attack window

Start by identifying every TerraMaster OS instance, including systems that may not appear in central inventories because they sit on edge networks, lab segments, or small-office deployments. For exposed appliances, confirm whether the management interface is reachable from untrusted networks and whether any compensating controls, such as filtering or segmentation, actually block inbound requests.

If the device is reachable, the next question is not simply whether a patch exists, but whether the system has already been exposed long enough for abuse. Review authentication logs, web access logs, shell history if available, process creation records, and any signs of unexpected outbound connections, new users, scheduled tasks, or configuration changes. On appliances like this, compromise often leaves only partial telemetry, so absence of evidence is not strong evidence of safety.

Incident teams can use the same operational discipline they would apply to a high-priority exploit chain by comparing exposure, exploitability, and remediation urgency, then checking vendor and CISA guidance for the exact fix path rather than relying on generic patching assumptions. For that workflow, the Vulnerability Management Guide is the most useful internal companion for prioritisation and verification.

What to do if patching must wait

If immediate remediation is not possible, reduce the reachable attack surface first. That usually means removing internet exposure, restricting access to trusted administrative networks, disabling unnecessary services, and placing the device behind stronger filtering or VPN-only access. Temporary containment is justified here because unauthenticated RCE is a direct compromise path, not a noisy prerequisite chain.

While the device remains in service, assume attacker dwell time may be short after public exploitation becomes known. Hunt for process anomalies, new binaries, unusual admin accounts, and outbound traffic that does not fit the appliance’s normal behaviour. If the device stores credentials, API keys, or other reusable secret material, rotate what the appliance could have exposed, especially if it had broad network reach or administrative integrations.

A practical containment mindset is to treat the appliance as potentially compromised until the fix is applied and the device is revalidated. For teams that need a reference point on how attackers abuse exposed keys, tokens, and unauthenticated endpoints after exploitation, The State of NHI & AI Agent Breach Report 2026 is useful background on how quickly initial access can turn into broader abuse.

Risk and Threat Considerations

Active exploitation changes the risk profile from “known weakness” to “probable attack path.” For a remote command execution flaw on an appliance, the main threat is direct code execution followed by persistence, lateral movement, data access, or ransomware staging. Systems that sit on flat networks or hold administrative trust are especially exposed.

Failure mechanism: An unauthenticated request reaches the vulnerable command execution path and the appliance accepts attacker-supplied commands as trusted input. Once that happens, the attacker can run reconnaissance, download tools, alter configuration, or pivot to adjacent systems.

Impact: The appliance can become an initial foothold, a pivot point, or a launchpad for broader compromise. If the device participates in file sharing, backups, or central administration, the blast radius can extend well beyond the appliance itself.

Practitioner Guidance

What to prioritise: Put exposed TerraMaster OS systems ahead of routine vulnerability queues, even if they are not the most critical assets on paper. Active exploitation and unauthenticated RCE make exposure, not asset value alone, the first sorting criterion.

What to verify: Confirm whether the device is reachable from untrusted networks, whether the vendor fix has actually been applied, and whether post-exploitation indicators have been checked after remediation. A patched system that has already been used as a foothold still requires validation.

Practitioner takeaway: For KEV-listed remote command execution flaws, the right question is not “is it patched yet?” but “could an attacker already have used it, and what else did that appliance expose?”

Related resources from NHI Mgmt Group

• CVE-2022-24990 (TerraMaster OS Remote Command Execution)
• Is CVE-2017-15944 (Palo Alto Networks PAN-OS Remote Code Execution) being exploited in the wild?
• Is CVE-2022-30525 (Zyxel Multiple Firewalls OS Command Injection) being exploited in the wild?
• Is CVE-2019-1579 (Palo Alto Networks PAN-OS Remote Code Execution) being exploited in the wild?