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, and because the products are end-of-life there is no fix to apply.

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, and the only remediation anyone has offered is to take the units off the wall. One reported endpoint carries both.

What it is#

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 the target. 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.

What an attacker needs#

A TCP route to the web interface. No credentials and no user interaction; PR:N/UI:N is the whole story.

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 the least of it. A device that cannot be patched cannot be cleaned in any way that lasts. 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.) What you are left with is an unmanaged foothold on the camera VLAN that has no closing date.

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 real 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. There is no basis here for patching one before the other, and no way to patch either.

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.

What "no patch" means operationally#

TWCERT/CC's advisories are not hedged. 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.

Note who wrote those. There is no GeoVision-published advisory anywhere in this record; both remediation strings belong to the coordinating CERT, and so 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." 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. The third is the only one with content, and it says removal.

So the remediation has no end state you control. 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 it stays open until the last unit comes down. Risk registers handle that badly. What usually happens is that the finding gets quietly reclassified as accepted while the firmware keeps accumulating defects nobody is going to fix.

One more thing about the record itself. Both identifiers came through TWCERT rather than through GeoVision, and the public trail on a discontinued line thins out fast. Read it accordingly: an absence of newer CVEs against a retired product tells you who stopped looking, not that it got safer.

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. Remote viewing should terminate at an authenticating gateway. Moving the web interface to a non-standard external port achieves nothing.
2. Default-deny egress from the camera VLAN, DNS included. The payload has to be fetched, and it then has to reach a C2. Breaking either half is an afternoon's work.
3. Alert on the device behaving as a client. These units originate almost nothing beyond RTSP, NTP and their recorder, so unexpected outbound TCP is high-signal here in a way it never is on a workstation.
4. Put a retirement date in the maintenance plan. A compensating control with no expiry becomes the architecture.

Rebooting is not on the list.

How to check#

• 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, since 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 is cheap and more often right than wrong. (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