Public exploit code for D-Link DIR-822A's 9.9 and 10.0 bugs lands before any fixed firmware

The L2TP bug is in tunnel_set_params, the routine that configures tunnel parameters ^[6]. When the daemon processes an L2TP control message, it copies fields from the packet into a fixed structure without checking that the source data fits ^[6]. A packet carrying more data than the destination holds overwrites the memory next to it ^[6].

What the attacker gets depends on what sits next to that structure. The minimum is a crash. Corrupting adjacent memory reliably kills the process, and on a small embedded device that can take the management plane offline ^[7]. The worse case is code execution. If the overwritten memory holds a return address or a function pointer, the attacker can redirect control flow, and the writeup attributes the 9.9 score to that path ^[8]. Whether it is reachable on a real unit depends on the exact build, the compiler's mitigations and the structure's layout, and the public disclosure does not settle any of those ^[9].

Attacker position should drive the response. The trigger is a malformed control packet from someone who already has network access to the router ^[10]. That means a foothold on the local network, or some other path for delivering L2TP control traffic to the daemon ^[10]. According to the dev.to writeup, this sets it apart from the companion DHCP flaw, which it says is often described as a remote, internet-facing pre-authentication bug ^[11].

A 9.9 on a bug that needs local access follows from where the device sits. A router is at the boundary of a home or small-office network, and control of it means control of the traffic that passes through it ^[17].

With no build to install ^[12], the choice for now is contain or replace. D-Link says it is reviewing the vulnerability, the affected product scope and its remediation options ^[14]. It has not confirmed whether other hardware revisions or older releases share the defect, so firmware A_101 is the only confirmed boundary ^[2][14].

Containment comes down to four controls: isolate the router from untrusted segments, turn off remote management on the WAN interface, restrict local access to known devices, and keep guest networks away from the administration interface ^[13].

Exposure counts need care. ZoomEye returned 624 assets for the model query `title="DIR-822"` and 6,697,454 for the vendor fingerprint `app="D-Link"` ^[15]. The model query is about one in 10,700 of the vendor-wide hits ^[1]. The vendor count covers every D-Link fingerprint regardless of firmware, and even the 624 only shows that DIR-822 family devices are reachable from the internet or a scanned network, not that any of them are exploitable ^[16].

I'd treat replacement as the default plan, with a fixed build as the thing that cancels it. The writeup's guidance is to watch D-Link's security publication page for a fixed build and replace the hardware if the vendor retires the model without a patch ^[18]. My context for that call is public proof-of-concept code and an unresolved code-execution question, on a device that carries every packet leaving the network ^[4][9][17].