GeoVision end-of-life devices are being exploited and no patch is coming

Discontinued GeoVision IP cameras, video servers, LPR units and DVRs carry two unauthenticated OS command injection flaws that CISA records as exploited. The products are end-of-life, so there is no fix to apply and the remediation is removal.

GeoVision had already stopped shipping firmware for this hardware when the first of these two CVEs was published. Both are unauthenticated command injection, both are in CISA KEV since 2025-05-07, and the only remediation on record is removing the units. One reported endpoint carries both.

The defect#

Both records describe the same defect: unfiltered user input reaching an OS command path on GeoVision network video hardware. Both carry CWE-78 and the identical vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H for a base score of 9.8 — NVD-assigned for CVE-2024-11120, TWCERT-assigned for CVE-2024-6047.

Only one source names an endpoint. Akamai's SIRT writes that "the exploit targets the _/DateSetting.cgi_ endpoint in GeoVision IoT devices, and injects commands into the _szSrvIpAddr_ parameter", and that "this command injection is tracked through both CVE-2024-6047 and CVE-2024-11120". Neither TWCERT advisory names an endpoint or a parameter. The attribution therefore rests on exploitation telemetry alone, with no disclosure document corroborating it. Treat the two CVEs as slices of one bug surface, and treat /DateSetting.cgi as the reported way in rather than a proven complete list.

Attacker prerequisites#

A TCP route to the web interface. No credentials, no user interaction: PR:N/UI:N.

Nothing in the record describes a targeting phase. The only documented use is botnet enrolment, which is consistent with untargeted scanning. (Inference.)

Impact and blast radius#

Command execution as the web service account. No source in the record states the privilege level for these SKUs; on this hardware generation that account is typically root. (Inference.) The only documented outcome is botnet enrolment: Akamai's payload is an ARM Mirai variant it tracks as LZRD, dropped as boatnet.arm7.

The flood traffic is not the main exposure. Mirai variants of this class are memory-resident, so a reboot kills the running process and leaves the reachable service exactly as it was; the record documents no reinfection timing for this particular campaign. (Inference.) A device that cannot be patched cannot be cleaned in any way that lasts, so the foothold on the camera VLAN stays open until the unit comes down.

How far that reaches depends entirely on network position. A GV-VS server bridging analogue cameras into an IP recorder usually routes to the VMS, to NTP, to the NVR's storage share, and through a flat switch often to the corporate VLAN. Root on such a box also sits upstream of the recorder, which puts stream tampering and RTSP credential recovery within reach. No source records anyone doing either. (Inference.)

Exploitation evidence#

Fact. Both CVEs were added to KEV on 2025-05-07 with a remediation due date of 2025-05-28. As of publication that deadline is 465 days past, and the listing itself is 486 days old. Ransomware use is recorded as Unknown for both.

Fact. The NVD description of CVE-2024-11120, published 2024-11-15, states that "this vulnerability has already been exploited by attackers, and we have received related reports." That is the reporter's claim carried into the record, roughly six months ahead of any public analysis.

Fact. Akamai SIRT published its analysis on 2025-05-06, the day before both KEV listings. It says the earliest exploit attempt against that URI its sensors saw was in early April 2025. It publishes Snort and YARA rules, the C2 domain connect.antiwifi.dev, and five C2 addresses: 209.141.44.28, 51.38.137.114, 176.65.144.253, 176.65.144.232 and 198.23.212.246.

Inference. EPSS on 2026-09-04 scores CVE-2024-11120 at 0.28386 (97.99th percentile) and CVE-2024-6047 at 0.10072 (95.31st percentile). The raw probabilities differ by a factor of 2.8, which looks like a prioritisation signal until you read the percentiles beside them: 2.7 points apart, both in the top five per cent of everything scored. For one injection against one parameter, that spread is an artefact of how much has been written about each identifier. The record gives no basis for treating one ahead of the other, and neither can be patched.

Not established. Nothing in these sources gives a count of exposed devices, a named victim organisation, or any incident narrative beyond botnet enrolment.

Affected products, and the gap in the record#

NVD's CPE data resolves 4 products for CVE-2024-11120 and 20 for CVE-2024-6047. They overlap on GV-DSP LPR and GVLX 4, so 22 distinct entries in total.

Before you build an asset query from that table: 20 of the 22 entries carry no version data at all. Only GV-DSP LPR and GVLX 4 have any, both recorded as 2.0 and 3.0. An absent version does not mean every firmware is affected, and it does not mean none is. It means nobody populated the field, and version matching will silently return nothing for most of this list.

Device types are missing from NVD too: all 22 CPE entries have a null product type. The categories come from TWCERT, which files GVLX 4 under DVR, GV-DSP LPR under DSP LPR, the GV-VS models under Video Server and the GV-BX, GV-CB, GV-EBL, GV-EFD, GV-FD and GV-FE models under IP Camera.

The two sources also disagree on scope, in both directions. TWCERT's CVE-2024-6047 page lists the family strings GV_VS28XX and GV_VS216XX; NVD expanded those into three named SKUs, GV-VS2800, GV-VS2820 and GV-VS21600. Any other model in those families is in scope by TWCERT's wording and absent from NVD. Going the other way, TWCERT scopes the LPR unit to GV_DSP_LPR_V2 on CVE-2024-6047 and to GV_DSP_LPR_V3 on CVE-2024-11120, while NVD records both 2.0 and 3.0 against both. Neither source contains the other, so an inventory sweep needs both open.

Operational meaning of "no patch"#

TWCERT/CC's advisories state the remedy directly. For CVE-2024-11120: "The affected devices are no longer being maintained. It is recommended to replace them." For CVE-2024-6047: "The product is no longer in surport. Please retire affected device." — "surport" is a typo in the original.

This record contains no GeoVision-published advisory. Both remediation strings belong to the coordinating CERT, as does the URL in the facts panel above.

CISA's required action reads in full: "Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable." Of the three clauses, the first is empty for a product whose vendor has stopped issuing instructions, the second does not apply to on-premise video hardware, and the third specifies removal.

Plan the remediation as a long one. A patch closes on a date you pick; replacement waits on procurement, a cabling survey, a mounting change and often a VMS licence change, and the finding stays open until the last unit comes down. Where that runs past a risk register's tolerance, the common outcome is reclassification as accepted risk while the firmware keeps accumulating defects nobody is going to fix.

Both identifiers came through TWCERT rather than through GeoVision, and the public trail on a discontinued line thins out fast. Do not read an absence of newer CVEs against this hardware as improvement; it records that reporting stopped.

If you cannot replace them this quarter#

1. Take the management interfaces off any routable path. A firewall rule permitting your NVR is not enough. Put them in a segment with no default gateway. PR:N makes every allowed source a full-compromise source, so cut the allowed sources to zero and add the recorder back as an explicit IP pair. Terminate remote viewing at an authenticating gateway. Do not rely on moving the web interface to a non-standard external port.
2. Default-deny egress from the camera VLAN, DNS included. The payload has to be fetched and the implant then has to reach a C2. Blocking either half breaks the chain.
3. Alert on the device behaving as a client. These units originate almost nothing beyond RTSP, NTP and traffic to their recorder, so unexpected outbound TCP is high-signal here.
4. Put a retirement date in the maintenance plan, and re-check items 1 to 3 against it at each maintenance window. The controls above are temporary by design and will otherwise stand in for the fix indefinitely.

Checks to run#

• Query the VMS for model strings rather than sweeping ports; these units often answer on non-default ports. Walk the GV-VS and GVLX families by hand for SKUs NVD never listed.
• Probe directly. GET /DateSetting.cgi returning anything other than a 404 puts that unit in scope whatever the CPE data says.
• Search proxy, firewall and device logs for /DateSetting.cgi requests carrying shell metacharacters in szSrvIpAddr. Retention on these boxes is short and volatile, so a clean search proves very little.
• Check historical flow data against the five C2 addresses Akamai published. A hit confirms compromise. No hit is not clearance: that infrastructure is over a year old and will have rotated.
• Where a device has been internet-exposed since April 2025, assume it was reached. Given AC:L and the absence of any targeting phase in the record, that assumption costs little. (Inference.)

Sources

1. GeoVision EOL devices - OS Command Injection (CVE-2024-11120). TWCERT/CC, 2024-11-15
2. GeoVision EOL device - OS Command Injection (CVE-2024-6047). TWCERT/CC, 2024-06-17
3. Active Exploitation of Mirai Variant in GeoVision IoT Botnet. Akamai SIRT, 2025-05-06
4. Known Exploited Vulnerabilities Catalog. CISA, 2026-09-04

Revision history