CVE-2024-6047

What it actually does

This is an unauthenticated remote OS command injection flaw in end-of-life GeoVision devices. A vulnerable device accepts attacker-controlled input in a management or device function and fails to neutralize shell metacharacters before passing that input to the underlying operating system. Because exploitation requires network access only, with no credentials or user interaction, an attacker can execute arbitrary system commands in the security context of the affected device service. Successful exploitation can allow full device compromise, including configuration theft, surveillance/video tampering, malware deployment, pivoting into adjacent networks, persistence, and denial of service. The CVSS 9.8 rating, CISA KEV listing, and active in-the-wild exploitation indicate high real-world risk. The affected-product metadata provided also lists several Linux kernel package lines with fixed versions; organizations should validate whether those package mappings are relevant to their asset inventory because the vulnerability description specifically identifies EOL GeoVision devices.

Why it matters to the business

Compromised GeoVision appliances can become attacker-controlled footholds inside a network, exposing video/security operations, credentials, internal network access, and device availability. Because these are end-of-life devices, normal vendor patch paths may be unavailable, making replacement or isolation more important than routine patching. Operational consequences may include loss of camera/NVR availability, tampering with monitoring evidence, participation in botnets, lateral movement into business systems, emergency device replacement, regulatory exposure if video or personal data is accessed, and incident response costs. The vulnerability is in the CISA Known Exploited Vulnerabilities catalog with a remediation due date of 2025-05-28, so organizations subject to CISA BOD 22-01 or similar policy should treat it as mandatory remediation. Although the provided ransomware flag is false, command execution on exposed edge devices is commonly used for botnet enrollment, credential harvesting, proxying, and follow-on compromise.

How an attack unfolds

An attacker first identifies internet-facing or reachable GeoVision devices, typically by scanning for device-specific web interfaces, banners, TLS certificates, page titles, or known URL structures. The attacker then sends a crafted unauthenticated request to the vulnerable function with input containing shell-control syntax or command-substitution content. Because the device does not correctly filter that input, the web or device service invokes the operating system shell with attacker-supplied commands. The attacker commonly confirms execution with a low-noise command, then downloads or stages tooling using built-in utilities such as wget, curl, tftp, ftpget, or busybox. After gaining execution, the attacker may enumerate the device, dump configuration files, retrieve credentials, alter recording or camera settings, install persistence, disable logging, deploy botnet malware, or use the device as a proxy/pivot into internal networks. In active exploitation, defenders should assume exposed vulnerable devices may have been probed or compromised even if only limited logs are available.

How to fix it

Prioritize removal, replacement, or strict isolation of affected end-of-life GeoVision devices because EOL products may not receive vendor fixes. If a vendor-supported firmware update exists for the specific device model, apply it immediately after validating model compatibility and backing up configurations. If no firmware fix is available, do not expose the device management interface to the internet; place it behind a VPN or zero-trust access layer, restrict access to dedicated management networks, and enforce firewall allowlists for only required administrative systems. Disable unused services, remove default accounts, rotate device and adjacent credentials, and monitor for unexpected outbound traffic. For devices that cannot be upgraded or replaced promptly, apply compensating controls such as network segmentation, egress filtering, WAF/IPS rules for command-injection patterns, and continuous logging of management traffic. The input also lists Linux package fixed versions; where those packages are actually present in inventory, update to at least the specified versions, including Debian linux 5.10.40-1, Ubuntu 20.04 linux-aws-5.15 5.15.0-1014.18~20.04.1, linux-azure-5.15 5.15.0-1007.8~20.04.1, linux-hwe-5.15 5.15.0-33.34~20.04.1, and Ubuntu 22.04 kernel lines such as linux 5.13.0-19.19, linux-aws 5.13.0-1005.6, linux-azure 5.13.0-1006.7, linux-gke 5.15.0-1002.2, linux-gkeop 5.15.0-1001.2, and linux-hwe-6.5 6.5.0-14.14~22.04.1. Validate package applicability against vendor advisories; OS kernel updates alone should not be assumed to remediate a vulnerable GeoVision appliance unless the affected asset is specifically one of those listed software packages.

How to confirm the fix worked

Build an inventory of all GeoVision devices and compare model, firmware, lifecycle status, and management exposure against the vendor advisory and CISA KEV entry. Confirm that no vulnerable management interfaces are reachable from the public internet using external scanning from a controlled vantage point. From internal networks, verify that only approved management hosts can connect to the device and that outbound egress from the device is restricted. Where firmware is available, confirm the running firmware version through the device UI, API, CLI, or asset-management tooling after upgrade. Where replacement or isolation is the remediation, validate firewall policy, segmentation, VPN requirement, and deny-by-default egress rules. Review HTTP access logs and device logs for command-injection probes before and after remediation. For listed Linux packages, validate with package manager queries such as dpkg, apt, or vulnerability-management tooling that installed versions are equal to or newer than the specified fixed versions. Finally, perform a safe authenticated configuration review and a non-destructive security test to confirm injected metacharacters are rejected or treated as data rather than executed.

Typical attack path

1. Scan the internet or internal address space for reachable GeoVision device web interfaces or management services.
2. Fingerprint the device model, firmware, and exposed functionality to determine whether it is an end-of-life vulnerable appliance.
3. Send an unauthenticated crafted request to the vulnerable function with command-injection syntax in a parameter or field processed by the device.
4. Verify command execution through response differences, timing behavior, DNS/HTTP callbacks, or creation of files/processes on the appliance.
5. Use built-in system utilities to download a second-stage script, malware binary, reverse shell, proxy, or botnet loader.
6. Establish persistence where possible by modifying startup scripts, scheduled tasks, init scripts, or device configuration.
7. Harvest configuration data, credentials, network details, camera/NVR information, and stored artifacts.
8. Use the compromised appliance to disrupt monitoring, tamper with recordings, launch scans, proxy traffic, or pivot toward adjacent internal systems.

How to detect it

Hunt across network, web, proxy, firewall, IDS/IPS, DNS, DHCP, NetFlow, EDR/NDR, and device logs for evidence that GeoVision appliances received crafted unauthenticated requests followed by command execution or unusual outbound connections. Prioritize devices that were internet-facing, exposed through port forwarding, managed remotely, or reachable from guest/vendor networks. In web access logs, look for requests containing shell metacharacters, command substitution, URL-encoded command separators, and downloader utilities. In DNS and proxy logs, look for GeoVision device IPs resolving or connecting to unfamiliar domains or direct IP addresses, especially immediately after suspicious inbound HTTP requests. In firewall/NetFlow data, look for new outbound traffic from camera/NVR subnets to the internet, high-volume scanning, connections to uncommon ports, or connections to known malware hosting infrastructure. On devices where shell access or forensic imaging is possible, review running processes, startup scripts, cron jobs, writable temporary directories, recently modified files, unknown binaries, and disabled or truncated logs. Common post-exploitation artifacts include downloads into /tmp, /var/tmp, /dev/shm, execution of busybox/wget/curl/tftp, chmod followed by execution, reverse-shell style network connections, and botnet process names. Because device logs may be limited or attacker-cleared, correlate multiple data sources and treat unexplained outbound traffic from a vulnerable device as suspicious.

• wget http://
• wget https://
• curl http://
• curl https://
• tftp -g
• ftpget
• busybox wget
• /bin/sh -c
• /bin/bash -c
• chmod +x /tmp/
• chmod 777 /tmp/
• /tmp/.
• /var/tmp/.
• /dev/shm/
• ;wget
• ;curl
• |wget
• |curl
• && wget
• && curl
• %3Bwget
• %3Bcurl
• %7Cwget
• %7Ccurl
• %26%26wget
• %26%26curl
• `wget
• `curl
• $(wget
• $(curl
• nc -e
• /bin/busybox
• /etc/init.d/
• crontab -e
• /var/spool/cron
• GeoVision

What your security team should do

• Immediately identify all GeoVision devices, especially internet-facing or remotely accessible appliances, and classify EOL models as high-priority remediation targets.
• Treat public exposure as urgent because the vulnerability is unauthenticated, network exploitable, CVSS 9.8, and listed in CISA KEV with active exploitation in the wild.
• Remove vulnerable EOL devices from internet exposure immediately; use firewall blocks, VPN-only access, management-network isolation, and egress restrictions while replacement is planned.
• Replace unsupported devices or upgrade to vendor-supported firmware where available; do not rely on compensating controls as a long-term fix for EOL command-execution flaws.
• Assume exposed devices may have been probed or compromised; collect logs, preserve forensic artifacts, and hunt for command-injection activity, suspicious downloads, and unknown processes.
• Rotate credentials stored on or used by affected devices, including local admin passwords, RTSP/ONVIF credentials, integration credentials, and any reused passwords.
• Deploy IDS/IPS/WAF detections for unauthenticated requests containing shell metacharacters and downloader commands targeting GeoVision management paths or device web services.
• Block unnecessary outbound traffic from camera/NVR networks, especially HTTP/HTTPS to untrusted destinations, DNS to unapproved resolvers, and common malware staging protocols.
• Validate any listed Linux kernel package fixes only on assets where those packages are actually applicable; reconcile scanner findings with vendor advisories to avoid false remediation assumptions.
• Document remediation evidence for KEV compliance, including asset inventory, exposure reduction, firmware/replacement status, and the 2025-05-28 due date where applicable.