One malicious message, sent from any device on the Wi-Fi, can give an attacker full control of a D-Link DIR-822A router, and there is no fix. The flaw, tracked as CVE-2026-86296, scores the maximum 10.0 out of 10 for severity. It needs no password and no click from anyone, instructions for triggering it are already public, and D-Link has not said whether a patch will ever come. Its own records suggest this model line reached end-of-life years ago.
Whoever controls a router controls everything that passes through it. A hijacked router can quietly send staff to fake login pages, watch a home worker's connection to company systems, probe every other device on the network, or be enlisted into the criminal botnets that have targeted D-Link routers for years. And these routers rarely sit in the server room. They are in branch office cupboards, installed by contractors who have long since moved on, and in the homes of staff who now work there three days a week, which is exactly why nobody thinks to check them.
In plain terms: if one of these routers is anywhere your business traffic flows, the plan is to find it and replace it, not to wait for a patch.
How this came to light
The vulnerability was reported by a security researcher credited as "tian" through VulDB, a vulnerability database that is also authorised to assign CVE identifiers. VulDB recorded the advisory on September 6, 2026, and CVE-2026-86296 was published the following day. A second flaw in the same router from the same researcher, CVE-2026-86510, was published on September 8. The researcher published technical write-ups and proof-of-concept code for both.
D-Link's own security announcement, SAP10516, followed on September 18 and was last updated on September 21. Its status is listed as "Open", and nearly every field an owner would need to act on, including the affected hardware revisions, the regions where the product was sold, the product's lifecycle status, and whether a security update will be released, is marked "Under Investigation" or "Under Confirmation".
Nothing in the public record says whether D-Link was contacted before the details went public. The timeline suggests the world and the vendor may have learned about this at roughly the same moment, which is part of why owners find themselves holding a public exploit with no vendor answer.
What is CVE-2026-86296?
CVE-2026-86296 is a stack-based buffer overflow in the DHCP component of the DIR-822A running firmware version A_101. DHCP is the service that hands out network addresses to devices when they join a network; on a home or small-office router, it is the thing that answers every laptop, phone, and smart device that connects over Ethernet or Wi-Fi.
The root cause
The flaw lives in the file udhcpcd/serverpacket.c, where the code uses strcpy, a classic C function that copies data from one place to another without checking whether the destination is large enough to hold it. When the router processes a specially crafted DHCP request, the attacker-supplied data is copied into a fixed-size buffer on the stack and runs past its end, overwriting neighbouring memory.
The title of the researcher's write-up indicates the problem sits in how the router parses a vendor-specific DHCP option associated with TR-111, a standard used by service providers to manage customer equipment remotely. That kind of rarely exercised parsing code, written for a niche feature and never revisited, is a familiar home for this class of bug.
One naming detail is worth knowing if you go digging. D-Link and the CVE record both describe the component as udhcpcd, which would normally suggest a DHCP client, but the file named, serverpacket.c, belongs to the DHCP server in the common embedded Linux toolchain. The public reporting, including BleepingComputer's, describes the flaw as being in the DHCP server, and the rest of this article follows that reading.
What an attacker can do
D-Link's advisory says successful exploitation may corrupt memory and could allow an attacker to affect the device's confidentiality, integrity, or availability. In practice, that spans two outcomes:
- At minimum, a crash. The DHCP service stops, and devices on the network can no longer obtain addresses. Repeated attempts keep it down.
- In the worse case, remote code execution. An attacker runs their own code on the router, which means full control of the device.
There is no authentication step and no user interaction. CISA's enrichment of the CVE record marks the flaw as automatable, meaning the steps to find and exploit vulnerable devices can be scripted at scale, with a total technical impact.
Who can reach it
This is the detail that matters most for prioritisation, and it is also the one the vendor has not spelled out. The CVSS vector records the attack vector as "Network", but a DHCP server answers devices that have joined the local network. BleepingComputer's reporting describes the attacker as someone without credentials on the same local network. That means anyone on the Wi-Fi, a guest who was given the password, a compromised smart plug or camera, or an infected laptop on the same network.
That has an uncomfortable consequence. D-Link's interim advice focuses on keeping the device off the public internet and restricting remote management. Both are sound hygiene, but neither obviously addresses an unauthenticated flaw in a service that answers the local network. An owner can follow every line of that advice and still be exposed to any device that joins their Wi-Fi.
The second flaw: CVE-2026-86510
D-Link's advisory covers a second vulnerability in the same firmware, reported by the same researcher, also with public proof-of-concept code.
| CVE | CVSS v3.1 | CVSS v4.0 (CNA) | Component | Type | Privileges | Precondition |
|---|---|---|---|---|---|---|
| CVE-2026-86296 | 10.0 (Critical) | 10.0 (Critical) | DHCP server (serverpacket.c) |
Stack-based buffer overflow | None | Attacker on the local network |
| CVE-2026-86510 | 9.9 (Critical) | 9.4 (Critical) | L2TP control message parser (tunnel_set_params) |
Out-of-bounds write | Low | Router configured for L2TP or L2TPv6 WAN connectivity |
CVE-2026-86510 is narrower. L2TP is a tunnelling protocol that some internet providers and VPN setups use for the connection between the router and the outside world, and most home and small-office owners never turn it on. If your router uses an ordinary DHCP or PPPoE internet connection, this second flaw is unlikely to be reachable. If it does use L2TP, treat it as equally urgent.
A note on the scores, since they will appear differently in different tools. The 10.0 and 9.9 figures were assigned by VulDB as the issuing authority. NIST's National Vulnerability Database has not independently analysed either record. When VulDB's CVSS v4 vector is run with its recorded exploit-maturity metric included, the result is 9.3 for CVE-2026-86296 and 8.6 for CVE-2026-86510. A ticket that says "CVSS 10" and one that says "CVSS 9.3" may well be describing the same flaw.
Who is affected?
| Model | Firmware | Hardware revision | Region | Security update |
|---|---|---|---|---|
| DIR-822A | A_101 | Under confirmation | Non-US (per D-Link's advisory title); scope under confirmation | Under investigation |
The advisory is headed "Non-US", so this is primarily a concern for organisations with sites, staff, or equipment outside the United States. Routers do travel, however, through grey imports, second-hand sales, and people relocating, so a non-US model turning up in a US home office is not impossible.
The end-of-life question
D-Link's advisory says the company is still verifying the product's lifecycle status. Its own archive suggests an answer may already exist. A separate D-Link announcement, SAP10372, states that all A and B hardware revisions of the non-US DIR-822 have reached End of Life and End of Service Life, and recommends that they be retired and replaced. That notice gives an end-of-support date written as "04/31/2018", a date that does not exist, but the intent is clear: support ended years ago. For comparison, the US and Canadian C and E revisions of the DIR-822 reached end of support on March 29, 2024.
Whether the DIR-822A in this advisory is the same product line as the DIR-822 rev A covered by that notice is exactly what D-Link says it is checking, so treat the link as likely rather than confirmed. There is, however, a clear precedent. SAP10372 itself exists because of CVE-2024-25331, an unauthenticated, LAN-side remote code execution flaw in the DIR-822 rev B, also reached through a stack-based buffer overflow. D-Link's answer then was retirement, not repair, and its published policy is that firmware development, including security patches, stops once a product reaches end of support.
The practical reading: plan as though no patch is coming. If D-Link does ship one, that is a welcome surprise rather than a plan.
Exploitation status: what we know
At the time of writing, neither D-Link nor CISA has reported exploitation in the wild, and neither CVE appeared in CISA's Known Exploited Vulnerabilities catalogue as of late September. Much of the coverage calls this a "zero-day", and it is worth being precise: strictly speaking, that label describes a flaw being exploited before a fix exists. What we have here is public exploit code and no fix, which is serious, but different.
The reason not to take comfort from that is history. Vulnerable D-Link routers are a long-standing favourite of botnet operators, who infect them with malware and use them to launch distributed denial-of-service attacks, proxy malicious traffic, and hide their origins. CISA's catalogue already tracks 26 D-Link vulnerabilities that have been exploited in attacks, two of which have also been used by ransomware groups. An unauthenticated, automatable flaw with public proof-of-concept code, on a device that will likely never be patched, is precisely the kind of entry that ends up on that list.
Why a home router is a business problem
For most organisations, a DIR-822A is unlikely to be in the server room. It is far more likely to be at a home worker's house, in a small branch office, or at a site where the person who set up the network has long since moved on.
A compromised router on the same network as a work laptop is in a powerful position. It controls which servers the laptop's DNS lookups resolve to, it sees traffic metadata, it can reach any service the laptop exposes on the local network, and it keeps that position across reboots and across every software update the laptop receives. Many security frameworks, including certification schemes such as Cyber Essentials, explicitly scope out routers the organisation did not supply, which is a reasonable scoping decision but not a description of the risk.
The controls that help here are the ones that stop trusting the local network in the first place: an always-on VPN that routes work traffic to a firewall the organisation controls, a host firewall on work devices that denies inbound connections, and authenticated, encrypted connections to business services. None of these repairs the router, but all of them reduce what a compromised router is worth.
What should you do?
1. Find out whether you have any
Ask home workers and branch sites to check the label on the underside of their router and send you the model, hardware revision, and firmware version. D-Link prints the hardware revision near the serial number, and it may also appear on the router's web management page. A photograph of the label is quicker than a form. Record anything you find in your asset register; a device that is not in a register is not being patched by anyone.
2. Plan to replace, not to patch
For any DIR-822 or DIR-822A, treat this as a replacement decision. A current, supported router with a published support end date costs far less than an incident, and replacement is the only action that actually removes the flaw. Monitor SAP10516 for changes, but do not let the possibility of a future update delay the replacement.
3. Reduce exposure until it is replaced
- Disable remote management from the internet side, and confirm the setting rather than assuming the default. This is D-Link's own advice; it is necessary, but on its own probably not sufficient for the DHCP flaw.
- Shrink who can reach the router. Change the Wi-Fi password, turn off guest networks that are no longer needed, and remove devices on the network that you cannot identify.
- Disable L2TP WAN connectivity if it is not genuinely required, which removes the path to CVE-2026-86510.
- Protect work devices independently with an always-on VPN and a host firewall that denies inbound connections, so a hostile router gains as little as possible.
4. Do not test it with the public exploit
It can be tempting to confirm vulnerability by running the published proof-of-concept against a suspect device. Do not. Memory corruption exploits routinely crash or brick routers, and a router stuck in a reboot loop at a home worker's house at nine in the morning is an outage you caused. Identify affected devices by label and firmware version.
5. Retire it properly
When the router is replaced, factory reset it and dispose of it through e-waste recycling rather than selling or donating it. A second-hand sale simply moves an unpatchable device onto someone else's network.
6. Fix the process that let it linger
Add one line to your procurement checklist: before buying any network device, record the manufacturer's published end-of-support date, and budget the replacement against that date. The next maximum-severity router advisory will find you through your asset register rather than through a news article.
Detection
Router compromises are hard to see from the outside, because consumer routers rarely provide useful logs and almost never run security monitoring software. What you can watch for:
- Unexplained DHCP failures, such as devices suddenly unable to obtain addresses, or the router dropping and restoring service without a power cut or configuration change. The crash path of this flaw stops the DHCP service.
- Unexpected router reboots or changes to settings nobody made, particularly DNS server addresses, port forwarding rules, or new administrative accounts.
- Unusual outbound traffic from the router itself to unfamiliar addresses, which network monitoring upstream of the router, or your internet provider, may be able to see. Botnet infections typically produce steady scanning or attack traffic.
- DNS anomalies on work devices, such as certificate warnings or sites resolving to unexpected addresses, which can indicate a router redirecting traffic.
If a router shows signs of compromise, disconnect it, replace it, and treat devices that were connected to it with some suspicion, starting with a review of their recent network activity and any credentials typed over that network.
A note on the pattern
The interesting failure here is not that a router from the last decade has a buffer overflow. It is that every part of the system did roughly what it was designed to do, and the owner still ends up unprotected. The CVE was published within a day of the advisory. CISA's enrichment added a sensible triage signal. D-Link published a candid notice saying it did not yet know the scope. Yet no one had a duty to tell the person using the router, and the person using the router probably does not know what model it is.
The question this raises for any organisation is not whether you run D-Link. It is whether, for every device that carries your business traffic, someone knows the date on which its manufacturer stops shipping security updates, and what happens in your budget on that date.
Summary
| CVE | CVE-2026-86296 (with related CVE-2026-86510) |
| Product | D-Link DIR-822A, firmware A_101 (non-US) |
| Type | Stack-based buffer overflow (strcpy) in the DHCP server component |
| CVSS | 10.0 v3.1 / 10.0 v4.0 (VulDB as CNA); 9.3 v4.0 with exploit maturity included |
| Attack requirements | No authentication, no user interaction; attacker on the router's local network |
| Impact | DHCP service crash; potential remote code execution and full device takeover |
| Reported by | Researcher "tian" via VulDB (VDB-399458) |
| CVE published | September 7, 2026 |
| D-Link advisory | SAP10516, published September 18, updated September 21, 2026; status Open |
| Public PoC? | Yes, for both CVEs |
| Active exploitation? | None reported; not in CISA KEV as of late September |
| CISA enrichment | Automatable: yes; technical impact: total |
| Patch available? | No; D-Link still investigating whether an update is "available or appropriate" |
| Lifecycle | D-Link notice SAP10372 lists non-US DIR-822 A and B revisions as end-of-life |
| Second flaw | CVE-2026-86510: L2TP out-of-bounds write, CVSS 9.9, low privileges, L2TP WAN required |
| Recommended action | Identify and replace affected routers; restrict network access and remote management in the meantime |
A perfect severity score, a public exploit, and a vendor that may never ship a fix add up to a simple conclusion: find these routers and replace them, rather than waiting for a patch that the product's history suggests is unlikely.
If you need help locating legacy network devices across home workers and branch sites, assessing whether a router may have been compromised, or putting an end-of-support tracking process in place, get in touch. The cheapest router incident is the one prevented by knowing what you own.