D-Link DIR-822A scored 10.0 with a public exploit, and D-Link still cannot say if a fix is coming

Fifteen days, two CVEs, and no firmware

CVE-2026-86296 was published on 7 September 2026. D-Link published its own notice, SAP10516, on 18 September, eleven days later. Today is 22 September, fifteen days after the CVE appeared, and the line in D-Link's affected product table under the heading Security Update still reads Under Investigation. So do the lines for hardware revision and region. The company says it is still verifying the applicable hardware revisions, the regional product scope, the product lifecycle status, and, in its own words, "whether an updated firmware release is available or appropriate".

That last phrase is the whole story. It is not a promise of a patch. It is a vendor keeping open the possibility that the answer will be a retirement notice.

What the fifteen days do not establish is more important than what they do. They do not establish that anyone is being attacked through this flaw. They do not establish that the router in question was ever sold in the United Kingdom, and D-Link's bulletin is headed Non-US, which narrows nothing useful for a British reader. They do not establish which hardware revisions carry the flawed code, because D-Link has not finished checking. And the maximum severity score that carried the story into the trade press was not assigned by D-Link or by NIST. It was assigned by the CVE Numbering Authority that issued the identifiers, VulDB, on the strength of a researcher's submission.

What the bulletin states, and what it leaves open

SAP10516 is unusually candid about its own gaps, which makes it a good document to read as an IT manager rather than as a headline. It is dated 18 September 2026 at 09:26 GMT, last updated 21 September at 09:55 GMT, and its resolved status is Open. It names the reporter, credits the CVE Numbering Authority, reprints the scores, and then declines to confirm almost everything an owner would need in order to act.

Read from D-Link security announcement SAP10516, published 18 September 2026 and last updated 21 September 2026

Question	Stated on the record	Not stated
Which product	DIR-822A, reported version A_101	Which hardware revisions are affected: listed as Under Confirmation
Which regions	Bulletin is headed Non-US	The geographic product scope: listed as Under Confirmation
Is there a fix	Security Update column reads Under Investigation	Any target date, and whether firmware is "available or appropriate"
Is it end of life	D-Link is verifying the product lifecycle status	Any lifecycle answer for the DIR-822A itself
Is it being exploited	A public proof of concept is reported	Any claim of attacks in the wild, by D-Link or by CISA
Who found it	Researcher credited as tian, a VulDB user	Whether the researcher contacted D-Link before publication

The last row deserves a moment. The CVE record's own timeline shows the advisory disclosed on 6 September and the VulDB entry created two hours later. D-Link's notice followed twelve days after that disclosure date. Nothing in either record says whether the vendor heard about the flaw before the world did. It is a coordination question, not an accusation, and it is unanswered.

There is also a naming wobble to flag if you go hunting for the code. D-Link's bulletin and the CVE record both call the component udhcpcd, while the source file named in the same record is udhcpcd/serverpacket.c. In the common embedded Linux toolchain, a file called serverpacket.c belongs to the DHCP server rather than the client. The researcher's own write-up title, as listed in the CVE references, describes a stack overflow in DHCP option parsing. We have not opened that write-up and we do not link it.

Two flaws, not one, and they are not equally reachable

Most coverage led on the 10.0. The bulletin actually carries two vulnerabilities, reported by the same researcher a day apart, in two different parts of the firmware. They have different prerequisites, and for a defender the difference matters more than the decimal point.

Compiled from the CVE records for CVE-2026-86296 and CVE-2026-86510 and the NVD API responses for both, retrieved 22 September 2026

Item	CVE-2026-86296	CVE-2026-86510
Component	udhcpcd, file serverpacket.c	L2TP control message parser, function tunnel_set_params
Weakness	CWE-121 stack-based buffer overflow	CWE-787 out-of-bounds write
Privileges needed	None (PR:N)	Low (PR:L)
CVSS 3.1 by VulDB	10.0 critical	9.9 critical
CVSS 4.0 base by VulDB	10.0 critical	9.4 critical
CISA enrichment	Proof of concept, automatable yes, impact total	Proof of concept, automatable no, impact total
In the CISA KEV catalogue	No, checked against the 21 September 2026 version	No, checked against the same version

Two details in that table are easy to misread. First, the 10.0 and the 9.9 are CVSS 3.1 base scores assigned by VulDB as the CNA. NVD has the records at a status of Deferred, so there is no independent NIST analysis to compare them against. Second, VulDB's published CVSS 4.0 vectors include the threat metric E:P, meaning a proof of concept exists. Fed through NVD's calculator, that same vector yields 9.3 for the first flaw and 8.6 for the second. Both figures are correct and they measure different things: 10.0 is the base score, 9.3 is the base plus the exploit maturity the CNA recorded. A ticket that says "CVSS 10" and a ticket that says "CVSS 9.3" can be about the same flaw.

The CISA enrichment line is the one to carry into a risk conversation. CISA's coordinator assessment marks the first flaw as automatable, meaning the reconnaissance and exploitation steps can be scripted at scale, and the technical impact as total. Consumer routers with automatable unauthenticated flaws are botnet feedstock, and CISA's own catalogue has twenty six D-Link entries, plus one shared with TRENDnet, on the 21 September 2026 version. None of them is this flaw. Yet.

Zero-day is a label, and remote management is not a control

The word zero-day is doing work in the coverage that the evidence does not support. In its strict sense it describes a flaw being exploited before a fix exists. Here there is public proof-of-concept code and no fix, which is a serious situation and a different one. Neither D-Link nor CISA has said the flaw is being used in attacks, and the KEV catalogue does not list it. A team that hears zero-day and reaches for its incident playbook is spending effort in the wrong place; a team that hears it and assumes an imminent patch is also wrong.

The comfortable label on the other side is the interim advice. D-Link tells customers to ensure the device is not unnecessarily exposed to the public internet, to restrict remote management, and to use firewall or network access controls to limit administrative access. Each of those is sound general hygiene. None of them is, on the face of it, a control for the flaw that scores 10.0. Remote management is a web interface. The flaw with no authentication requirement sits in code that names a DHCP server file. If our reading is right, an owner can follow every line of the interim advice and remain exposed to any device that joins the network, which includes a guest on the Wi-Fi, a compromised smart plug, or a family laptop with a browser extension nobody vetted.

That is the pattern to carry away. Advice that names an interface is not the same as advice that names the vulnerable component, and a vendor that has not finished identifying the affected hardware revisions is in no position to issue a targeted mitigation.

The shape of the gap

Ten days passed between the second CVE and the vendor's first public word, and another four have passed since. For a device class that attackers scan for continuously, the useful number is not the vendor's response time but the owner's: how long a small business would take to discover it has one of these routers at all. For most of the organisations this site is written for, the honest answer is that nobody is looking, because the router belongs to a home worker, or was installed by a contractor in 2019, or sits in a branch office cupboard under a coat.

The end-of-life question D-Link has not answered, and the one it already did

D-Link's bulletin says the product lifecycle status is still being verified. Its own archive suggests the answer may already exist. A separate D-Link support announcement, SAP10372, states that the DIR-822, in all A and B hardware revisions of the non-US product, has reached End of Life and End of Service Life. That notice gives an end of support date written as 04/31/2018, a date that does not exist, and was last updated on 30 January 2024. The same notice lists the US and Canadian C and E revisions with an end of support date of 29 March 2024.

Whether the DIR-822A named in this month's bulletin is the same product line as the DIR-822 rev A covered by that notice is exactly what D-Link says it is still checking. The model string in the researcher's submission, DIR822A_101, reads like a hardware revision A firmware build, but that is a guess from a filename and we treat it as one. If it turns out to be the same family, the practical consequence is blunt: the affected owners have been outside vendor support for about eight years and four months, and no firmware is coming.

There is precedent in the same document. SAP10372 exists because researchers at Ensign InfoSecurity reported CVE-2024-25331, described there as a LAN-side unauthenticated remote code execution flaw in the DIR-822 rev B, reached through a stack-based buffer overflow. D-Link's answer then was retirement, not repair. Its published end-of-life policy says the plain part out loud: after the End of Support date the company will no longer develop, repair, maintain or test the product firmware, including providing bug fixes and security patches.

D-Link is not behaving unusually here, and it is not obliged to support a router indefinitely. State its commercial interest plainly rather than sneer at it: a retirement notice costs a support announcement, and a firmware release for a decade-old chipset costs engineering time on a product that generates no revenue. The lesson is not that D-Link is delinquent. It is that the lifecycle answer is the security answer, and most buyers never ask for it at purchase time.

One more data point on how normal this is. Of the twenty recent announcements listed on D-Link's support announcement page on 22 September 2026, nineteen concern vulnerabilities and one concerns battery safety. Fourteen of those nineteen have End of Life or End of Service in the title. The modal D-Link security announcement is not a patch note. It is an obituary.

PSTI: what the UK regime actually promises

Since 29 April 2024 the United Kingdom has had a product security regime for consumer connectable products, made up of Part 1 of the Product Security and Telecommunications Infrastructure Act 2022 and the PSTI (Security Requirements for Relevant Connectable Products) Regulations 2023. Routers are squarely the kind of product it was written for. Be precise about what it requires, because the regime is regularly described in a way that implies a guaranteed support life, and it does not provide one.

Schedule 1 of the 2023 Regulations imposes three requirements on manufacturers: passwords must be unique per product or set by the user, information on how to report security issues must be published, and information on minimum security update periods must be published. That third requirement is a publication duty. The Regulations define the defined support period as the minimum length of time, expressed with an end date, for which security updates will be provided. The law requires the manufacturer to publish it, to publish any extension promptly, in English, free of charge, and in language a non-technical reader can understand. It forbids shortening the period after publication. It does not set a floor. A manufacturer that publishes an end date of next Tuesday has complied with the letter of the requirement.

Read from the PSTI Act 2022 Part 1 and the PSTI (Security Requirements for Relevant Connectable Products) Regulations 2023, with the DSIT and OPSS guidance on the regime

What PSTI does	What it does not do
Requires the defined support period to be published with an end date, clearly and free of charge	Sets no minimum length for that period, and no minimum for any product category
Applies from 29 April 2024 to manufacturers, importers and distributors making products available in the UK	Reaches back to nothing: a router supplied to its owner before that date was never covered
Covers products made available to UK consumers, and business sales of products identical to consumer ones	Excludes a product that was already supplied to a customer, which takes the second-hand market out of scope
Requires a statement of compliance to accompany the product, retained for at least ten years	Requires no notice to existing owners when support ends, and no fix for any particular vulnerability
Is enforced by the Office for Product Safety and Standards, with penalties up to ten million pounds or four per cent of qualifying worldwide revenue	Does not make an unpatched legacy router unlawful to own, sell second hand or keep running in a business

Apply that to the device in this story. If a DIR-822 or DIR-822A entered a UK home before 29 April 2024, no PSTI duty ever attached to that unit, and there is no published support end date to hold anyone to. If the same unit is later sold on eBay, section 54 of the Act takes it out of the definition of a UK consumer connectable product, because it has already been supplied to a customer. The regime is a forward-looking labelling and baseline regime. It improves what you can learn at the point of purchase. It does nothing whatever for the installed base, which is where every one of these advisories lands.

We could not establish whether the DIR-822A was ever sold in the United Kingdom. D-Link's UK product pages do not list it, and the bulletin's Non-US heading does not tell us which non-US markets are meant. Any UK exposure would most likely come through grey imports, second-hand sales or devices carried between countries, and we have no data on volumes. That is a gap, and it is the honest position.

The home-working router that your certification does not cover

For a small business, the DIR-822A is unlikely to be in the server cupboard. It is far more likely to be the box a member of staff plugged in years ago and forgot, in the house where they now work three days a week.

Cyber Essentials draws the line explicitly. In the Requirements for IT Infrastructure v3.3, dated April 2026, the scheme says that if the organisation gives the home or remote worker a router, that router is in scope. All other routers are out of scope, and the organisation must instead apply firewall controls such as a software firewall on the user's device. Wireless devices that are part of an internet provider's router at the home location are also out of scope, and the scheme states that it is not concerned with attacks that can only be launched within the signal range of a wireless device.

That is a reasonable scoping decision for a certification scheme. It is not a description of your risk. A compromised router on the same network as a work laptop sits in a position of considerable advantage: it resolves the laptop's DNS, it sees traffic metadata, it can reach services the laptop exposes to its local network, and it keeps that position across reboots and across any software update the laptop receives. The certificate on the wall is silent about it by design.

The mitigations that actually survive this scoping gap are the ones that stop trusting the local network. An always-on VPN moves the device's internet boundary to a firewall the organisation controls, which Cyber Essentials itself recognises. A host firewall configured to deny inbound connections removes most of what a neighbouring device could reach. Certificate-pinned or mutually authenticated connections to business services reduce what a hostile gateway can do with the traffic it carries. None of these repairs the router. All of them reduce what a compromised router is worth.

The same reasoning covers a branch office, a serviced desk in a shared building, a market stall with card payments over a pocket router, and any site where the person who installed the network no longer works for you.

What to do, in the order worth doing it

The question that exposes the gap

The interesting failure here is not that a router from the middle of the last decade has a buffer overflow. It is that three separate systems all did roughly what they were designed to do, and the owner of the device still ends up unprotected. The CVE system published a score within a day. CISA's enrichment added a sensible triage signal within another. D-Link published a notice eleven days after the CVE and said, truthfully, that it did not yet know the scope. The UK's product security regime requires manufacturers to tell buyers when support ends, and it did not apply to a device sold before April 2024. Every part worked. Nobody had a duty to tell the person using the router.

So the question to put to your own organisation is not whether you run D-Link. It is this: for every device that carries your business traffic, who holds the date on which its manufacturer stops shipping security updates, and what happens in your budget on that date? If the answer is that nobody holds it, then the next maximum severity advisory will find you the same way this one found the DIR-822A owners, which is to say through a news article about a product you did not know you had.