CVE-2026-124560: D-Link DIR-878 Heap Overflow
Critical CVSS (9.8) reachable over network.
TL;DR - CVE-2026-124560 is a CVSS 9.8 remote heap-based buffer overflow in D-Link DIR-878 firmware 1.20B05. - The product is unsupported; no fixed firmware version was identified, so replace or isolate affected routers. - A public exploit reference exists, but active exploitation is not confirmed by CISA KEV or the reviewed sources.
CVE-2026-124560 is a critical D-Link DIR-878 vulnerability affecting firmware 1.20B05. The flaw is a remote heap-based buffer overflow in the HNAP Handler’s GetCAPTCHAsetting function. Because the router is unsupported and no fixed firmware was identified, organizations should prioritize replacement or isolation.
Are You Affected?
CVE-2026-124560 affects the D-Link DIR-878 wireless router running firmware 1.20B05. The vulnerable code is in bin/prog.cgi, specifically the HNAP Handler’s GetCAPTCHAsetting function. The NVD record identifies firmware 1.20B05 as affected and describes the product as no longer supported by its maintainer.
| Field | Assessment |
|---|---|
| CVE ID | CVE-2026-124560 |
| CVSS score | 9.8 / 10.0, Critical |
| Attack vector | Remote |
| Authentication required | Not explicitly stated in the available NVD record |
| Affected product | D-Link DIR-878 |
| Affected version | Firmware 1.20B05 |
| Vulnerable component | HNAP Handler, bin/prog.cgi, GetCAPTCHAsetting |
| Patch available | No vendor patch or fixed version identified |
| Support status | Product described as unsupported or end-of-life |
No additional affected DIR-878 firmware versions were identified in the available NVD data. Independent references describe 1.20B05 as the final firmware release, but that detail was not confirmed through a primary D-Link advisory. Administrators should verify the installed firmware locally and treat any DIR-878 running 1.20B05 as affected unless D-Link provides authoritative contrary information.
The authentication requirement is not explicitly stated in the available record. Do not assume that a login is required merely because the vulnerable function is part of a management component. Exposure depends on whether the HNAP interface is reachable from an attacker-controlled network and how the device is configured.
For general guidance on reducing exposure from unsupported equipment, see this secure self-hosted services checklist.
The Fix, If You’re in a Hurry
No fixed firmware version was identified in the retrieved NVD references or search results. The affected device is described as unsupported, and available evidence indicates that 1.20B05 may be the final DIR-878 firmware release. Accordingly, there is no confirmed upgrade target such as “upgrade to version X.Y.Z.”
The preferred fix is to replace the DIR-878 with a currently supported router. If replacement cannot occur immediately:
- Remove the router’s management interface from the public Internet.
- Disable remote administration and unnecessary HNAP-related functionality where the device permits it.
- Restrict administrative access to a trusted management network.
- Review firewall and network-flow logs for suspicious management activity.
- Schedule replacement as soon as practical.
These actions reduce exposure but do not repair the vulnerable binary.
Technical Notes
There is no confirmed vendor upgrade command because no fixed firmware image was identified. Do not script an upgrade to an unverified image or assume that a later DIR-878 version exists. Use the device’s documented administrative interface to confirm the installed firmware, then schedule replacement.
For network controls, apply an equivalent deny policy on the upstream firewall. The exact service and port used by HNAP can vary by device configuration, so identify the router’s exposed management services before writing the rule. A generic example using nftables to block administrative access from an untrusted interface is:
sudo nft add rule inet filter input iifname "wan0" tcp dport { 80, 443 } drop
This example is not a substitute for vendor documentation or a complete firewall policy. Validate the interface name, management ports, and rule ordering in a maintenance window. Preserve trusted administrative access through a dedicated management network.
Analyst’s Take: Replacement should come before detection tuning. The device is unsupported, no fixed firmware version was identified, and the available record does not establish that the vulnerable function requires authentication. Isolation reduces exposure while replacement is pending, but it does not remove the vulnerable binary.
How This Vulnerability Works
The flaw is a heap-based buffer overflow in the HNAP Handler’s GetCAPTCHAsetting function within bin/prog.cgi. According to the NVD description, manipulating the uid argument causes data to exceed the bounds of a heap allocation. Heap corruption can damage adjacent objects, crash the process, or potentially alter program control flow.
The available record does not provide the vulnerable instruction, allocation size, field layout, exploit chain, or confirmed post-overflow impact. It therefore cannot establish whether reliable arbitrary code execution is possible on all affected configurations. The CVSS 9.8 rating indicates critical risk, but defenders should distinguish the severity score from a validated description of the exact exploitation outcome.
The remote attack surface is the important operational issue. If an attacker can reach the HNAP request handler over a network, they may be able to submit a crafted uid value without first gaining local access to the router. Internet exposure, port forwarding, compromised internal hosts, and untrusted wireless or guest segments can all affect practical exploitability.
Technical Notes
The vulnerable request parameter is identified as uid. A safe detection exercise should not replay an exploit payload against production equipment. Instead, inspect HTTP or HNAP request metadata for unusually long, malformed, encoded, or rapidly varying uid values. Do not log credentials, session tokens, or complete sensitive request bodies.
A conceptual request pattern may resemble the following, but should not be sent to a production router as a test:
POST /bin/prog.cgi HTTP/1.1
Host: router.example
Content-Type: application/x-www-form-urlencoded
uid=<unexpectedly-long-or-malformed-value>
The exact method, path, encoding, and headers used by a real request are not established by the available research note. Treat this as a logging and review pattern, not a complete signature.
Severity, Explained
CVE-2026-124560 has a reported CVSS score of 9.8 out of 10.0, classified as Critical. The available NVD response supplied the score but did not include the complete CVSS vector string. Consequently, individual metric values such as precise privileges required, user interaction, scope, confidentiality impact, integrity impact, and availability impact cannot be stated reliably from the supplied data.
The record does explicitly identify remote attack initiation, which supports treating network exposure as a priority. The absence of a confirmed authentication requirement is also operationally significant: administrators should not assume that placing the router on an internal network makes it safe if untrusted hosts can reach the HNAP interface.
A CVSS score is a prioritization aid, not proof of exploitation success in every deployment. Device exposure, management-plane configuration, segmentation, firmware behavior, and exploit reliability all affect real-world risk. Here, the combination of a critical rating, remote trigger, public exploit reference, and unsupported product status justifies urgent replacement or isolation.
Is It Being Exploited?
The NVD record states that the exploit has been made public and could be used. It also lists a GitHub reference that appears to correspond to a proof of concept or research repository:
https://github.com/Zimo-666/DIR-878-cves/tree/main/01-captcha-uid-heap-overflow
The referenced path returned HTTP 404 during retrieval, so its current contents and availability could not be independently verified. The URL should be treated as an NVD-listed reference, not as a validated operational exploit until defenders inspect it through their own approved research process.
Active exploitation in the wild is not confirmed by the reviewed sources. CVE-2026-124560 is not listed in the CISA Known Exploited Vulnerabilities catalog. Therefore, there is no CISA KEV addition date, remediation deadline, ransomware-campaign designation, or CISA-confirmed exploitation status for this CVE. Lack of KEV inclusion does not prove that attacks are impossible or that the vulnerability is not being probed.
The current assessment is:
| Question | Status |
|---|---|
| Is a public exploit or PoC reference reported? | Yes, according to the NVD record |
| Was the referenced GitHub path independently verified? | No; retrieval returned 404 |
| Is active exploitation confirmed by CISA KEV? | No |
| Is exploitation in the wild otherwise established by the reviewed sources? | Not established |
| Is ransomware use reported in CISA KEV? | No KEV designation |
Detecting It in Your Environment
Start with asset discovery. Identify every D-Link DIR-878 device, record its firmware version, and determine whether its administration or HNAP-related services are reachable from the Internet, guest networks, wireless client segments, or untrusted internal systems. A device that cannot be centrally inventoried should be considered a visibility gap, not an assumed false positive.
Review firewall, reverse-proxy, router, and network-flow logs for inbound connections to the DIR-878 management address, especially from unexpected external sources. Also look for repeated requests to administrative paths, malformed HTTP requests, large request bodies, unusual uid parameters, router reboots, configuration changes, and outbound connections that began immediately after suspicious management traffic.
Technical Notes
A generic Splunk query can help identify suspicious requests if HTTP logs include request paths and parameters:
index=network sourcetype=http
(uri_path="/bin/prog.cgi" OR uri="/bin/prog.cgi")
| search uri_query="*uid=*"
| eval uid_len=coalesce(len(uri_query), 0)
| stats count values(src_ip) as sources max(uid_len) as max_query_length
by dest_ip, http_method, uri_path, status
| where count > 5 OR max_query_length > 512
This is a starting point, not a validated exploit signature. Parameter encoding, logging normalization, and field names differ across products. Tune the query against known-good HNAP traffic and avoid assuming that every request to /bin/prog.cgi is malicious.
For Suricata or another network IDS, begin with a narrow alert for requests containing the vulnerable path and parameter, then review false positives:
alert http any any -> $HOME_NET any (
msg:"Possible D-Link DIR-878 HNAP uid parameter access";
flow:established,to_server;
http.uri;
content:"/bin/prog.cgi";
http.request_body;
content:"uid=";
nocase;
sid:900124560;
rev:1;
)
This rule does not detect heap corruption and should not be described as a confirmed CVE signature. It identifies traffic that merits investigation. Correlate alerts with source reputation, request length, router crashes, configuration changes, and post-request outbound activity.
If the router reboots unexpectedly or its configuration changes, preserve logs and configuration backups before resetting it. Because consumer routers often have limited forensic capability, use upstream firewall and DNS logs to reconstruct connections. Consider the device potentially compromised if suspicious traffic coincides with administrative changes or unexplained outbound sessions.
References and Further Reading
The primary vulnerability record is the NVD description for CVE-2026-124560. It identifies the affected product and firmware, the HNAP Handler component, the GetCAPTCHAsetting function, the uid argument, the heap-based buffer overflow, remote attack initiation, and the reported public exploit status.
The available references include:
- NVD-listed GitHub research or PoC reference:
https://github.com/Zimo-666/DIR-878-cves/tree/main/01-captcha-uid-heap-overflow - VulDB CVE page:
https://vuldb.com/cve/CVE-2026-124560 - VulDB submission reference:
https://vuldb.com/submit/1035616 - VulDB vulnerability reference:
https://vuldb.com/vuln/432892 - VulDB CTI reference:
https://vuldb.com/vuln/432892/cti
The GitHub path returned 404 during the reviewed retrieval attempt, and the VulDB page returned 403. No D-Link vendor advisory or fixed firmware notice was identified. Organizations should verify current vendor support status and firmware availability directly through D-Link’s official support channels before relying on third-party firmware claims.
For additional context on privilege escalation terminology and vulnerability triage, see our privilege escalation glossary. That concept is distinct from this vulnerability’s confirmed description: the available record identifies a remote heap overflow but does not establish a complete post-compromise privilege-escalation chain.
For incident response, retain firewall logs, router configuration exports, DHCP records, DNS logs, and management-access logs. If the DIR-878 was Internet-exposed, assume that public exploit availability increases the chance of opportunistic scanning even though CISA KEV does not confirm active exploitation. Replacement remains the strongest remediation because configuration hardening cannot remove the vulnerable code.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.