Is CVE-2024-6047 (GeoVision Devices OS Command Injection) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2024-6047 to its Known Exploited Vulnerabilities catalogue on 7 May 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Multiple GeoVision devices contain an OS command injection vulnerability that allows a remote, unauthenticated attacker to inject and execute arbitrary system commands.

What the KEV listing means for active exploitation

CISA listing is the practical signal that matters here: it means the vulnerability has moved from theoretical exposure to confirmed attacker use. For a remote, unauthenticated OS command injection issue, the key question is not whether exploitation is possible, but whether affected devices are still reachable, internet-facing, and allowed to execute attacker-supplied commands.

For a vulnerability of this type, the difference between “patched eventually” and “exploited in the wild” is often measured in hours or days, not normal change windows. The most useful response is to treat the device class as potentially targeted until exposure is removed, even if no compromise has yet been detected.

How to confirm exposure and reduce the attack surface

Start by identifying every GeoVision device, model, and deployment path that could plausibly accept remote requests. That includes devices hidden behind port forwarding, reverse proxies, VPN exceptions, remote management paths, and any instance that was never added to a formal asset inventory.

If you are unsure whether a system is in scope, defer to the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for the authoritative remediation target, and use the CVE Program record to keep the vulnerability identity consistent across tickets, scanners, and incident notes. For prioritisation, the FIRST EPSS model can help rank exposure when remediation capacity is limited, but it should not override KEV status.

Where patching is not immediate, shrinking the reachable surface matters more than perfect tuning. Remove public exposure, restrict management access to trusted administrative networks, and watch for any device that can still be contacted from untrusted segments.

What to do if patching must wait

If you cannot remediate at once, the safest interim control is to make the vulnerable service unreachable from the internet and from broad internal networks. In parallel, tighten any upstream access control, disable unnecessary remote functions, and preserve logs so you can inspect requests that may already have attempted injection.

The NIST Cybersecurity Framework 2.0 is useful here because it frames the issue as a combined identify-protect-detect problem: know which devices exist, protect the exposed path, and detect abnormal command execution or administrative changes. For operational hardening of the device layer, the CIS Benchmarks are the right style of reference where a benchmark exists for the underlying platform or supporting system.

If the appliance supports it, disable features you do not use, rotate any administrative credentials that may be stored locally, and assume that simple network segmentation is not enough if the service itself remains reachable through an allowed path.

What earlier compromise checks should look for

Because the flaw allows arbitrary command execution, post-exploitation activity may look like ordinary administration unless you inspect for it deliberately. Review device logs, authentication events, configuration changes, unexpected outbound connections, and any signs of new users, scripts, binaries, or scheduled tasks that were not part of normal maintenance.

Hunt for indicators that suggest the device was used as a staging point rather than only as the initial target. On embedded and appliance-class systems, attackers often favour lightweight persistence, log tampering, and credential harvesting over noisy payloads, so absence of obvious malware is not reassuring by itself.

If the device has privileged integrations with adjacent systems, treat those integrations as potentially exposed until you verify otherwise. A command injection foothold on an edge device can quickly become a pivot into management networks or monitoring infrastructure if the appliance has stored trust material.

Risk and Threat Considerations

Remote unauthenticated command injection on a network-accessible device is high-risk because exploitation can happen before defenders have a chance to authenticate, verify, or limit the request. Once a device accepts attacker-controlled commands, the attacker can move from access to execution with very little friction.

Failure mechanism: The service processes untrusted input as shell syntax or command arguments, allowing a remote attacker to run arbitrary system commands, alter configuration, or plant persistence without valid credentials.

Impact: The most likely consequences are full device compromise, recon and pivoting into adjacent networks, theft of stored secrets or session material, service disruption, and use of the device as a launch point for follow-on intrusion.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while 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
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The issue is active exploitation of a remotely reachable service.
Recommendation — Map observed probes and command execution to public-facing exploitation and hunt for follow-on activity.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV status makes rapid exposure identification and remediation the key operational control.
Recommendation — Prioritise and remediate KEV-listed devices before lower-risk findings.
NIST CSF 2.0	DE.CM-09 — Malicious Code Detected	Command injection exploitation calls for monitoring abnormal execution and compromise signals.
Recommendation — Monitor device logs and execution anomalies for signs of exploitation.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	The vulnerability is an input-validation failure that enables command injection.
	SI-3 — System Monitoring	Post-exploitation checks depend on detecting unauthorized changes and abnormal behaviour.
Recommendation — Validate and constrain all external input before it reaches command execution. Log and review suspicious execution, configuration change, and persistence activity.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as an exposure management issue first, not a ticketing exercise. If the device is reachable from outside trusted administrative boundaries, isolate it before you spend time on forensics or tuning.

What to verify: Confirm three things before you trust the environment again: the device is no longer reachable by untrusted users, the vulnerable code path is remediated or disabled, and the device has not been used to reach anything else.

Decision rule: If the device cannot be patched immediately, remove exposure and collect evidence at once. If you can patch, still perform compromise checks after remediation because active exploitation may have occurred before the fix was applied.

Practitioner takeaway: With a KEV-listed command injection flaw, the real decision is whether you can still justify the device’s current level of trust. If you cannot prove it was unreachable or untouched, assume hostile use until evidence says otherwise.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org