SURIQ
An undocumented admin password is baked into the firmware of at least five Tenda router models, and on July 7 the CERT Coordination Center (CERT/CC) confirmed there is no fix. That pairing, a network-edge device you cannot patch and a credential anyone reading the advisory now knows exists, changes the job from apply the update to assume it is reachable and contain it. The flaw, CVE-2026-11405, was reported by an anonymous researcher; Tenda has not acknowledged it. If one of these routers sits in front of anything you care about, the clock started when the advisory went public.
What CERT/CC actually found
The backdoor lives in /bin/httpd, the router's web management server. According to CERT/CC, when a normal login fails the login() routine does not stop there. It takes an alternate code path, pulls a value stored as sys.rzadmin.password from the device configuration, and does a plaintext comparison against whatever password was supplied. Match it and you get role=2, full administrative access to the web interface, no matter what the real admin credentials are.
The username does not matter either. The associated rzadmin account name is never validated, so any username paired with the backdoor password succeeds. This is the shape of a factory or service credential that should have been stripped before shipping and was not. CERT/CC credits an anonymous researcher for the finding, and both The Hacker News and Security Affairs report Tenda has not responded.
Five firmware builds are named in the advisory:
| Model | Affected firmware build |
|---|---|
| FH1201 | V1.2.0.14(408) |
| W15E | V15.11.0.5(1068_1567_841) |
| AC10 | V15.03.06.46 |
| AC5 | V15.03.06.48 |
| AC6 V2.0 | V15.03.06.51 |
No CVSS score was published with the advisory at the time of writing, and there is no report of exploitation in the wild yet. Neither of those is comfort. A hardcoded credential that grants full admin needs no chain and no skill to use, and the mechanism is now public.
Why "no patch" is the whole story
Most vulnerability writeups end on a version number: upgrade to the fixed build and move on. This one has no fixed build and a vendor that has gone quiet. That inverts the usual priority math. There is no due-date to track, no severity rating to weigh against your patch queue, because there is nothing to install. The only variable you control is exposure, and the only clock that matters is how fast you remove it.
We have watched this exact pattern before. A forgotten router quietly conscripted into scanning, embedded devices carrying flaws their makers will never fix, and ransomware crews walking in through the edge gear nobody patched. Consumer and small-office networking hardware ships, sells, and then falls off the vendor's support map while it keeps forwarding your traffic. A built-in password is just the most direct version of the same problem: the device you cannot update is the device an attacker owns on their schedule, not yours.
How exposed are you, really
The instinct is to read "consumer router" and stop caring. That misjudges where the risk sits. The exposure is not the router; it is everything behind the router that trusts it. Whoever holds admin on one of these devices can repoint its DNS, add a port forward that quietly exposes an internal host, capture and reroute traffic, or flip settings to open a path inward. In a home that is bad. In a branch office, a retail site, or a remote worker's setup that backhauls into real infrastructure, it is a pivot.
So the honest question is not "do I run a Tenda router" but "what sits on the segment one of these routers can reach." If the answer includes servers, management interfaces, or a VPN back to the core, the branch router is now part of your attack surface whether it is on your asset inventory or not. This is the same lesson as any baked-in default secret: the credential's blast radius is defined by what it can reach, not by what the device is called.
Detecting a takeover the device will not log for you
Here is the uncomfortable part for defenders. The bypass is a plaintext string compare inside /bin/httpd on hardware you do not control the logging on. You will most likely not see the malicious login as an event, and you cannot bolt an agent onto the router to watch for it. So stop trying to detect the authentication. Detect the blast radius instead.
The signals that a router admin takeover leaves are downstream and observable from the network you do control:
- DNS settings that changed without a change request, or clients resolving names through a resolver you did not configure.
- New or unexpected port forwards, or inbound connections reaching internal hosts that were never meant to be reachable.
- Outbound connections originating from the router's own address to destinations it has no reason to talk to.
- Configuration drift: remote management flipped back on, admin sessions from a WAN address, firmware or settings that no longer match your known-good baseline.
None of that requires touching the router. It requires watching the traffic and the config state around it, which is exactly where a defender still has room to act when the device itself is a black box.
What to do this week
CERT/CC's two mitigations are the right first moves, and both are things you do to the router, not fixes you wait on:
- Turn off remote (WAN-side) management now. The backdoor is only as dangerous as its reachability. If the web interface is not exposed to the internet, an external attacker cannot reach the alternate login path from outside.
- Change the default LAN IP. CERT/CC recommends this to frustrate automated tools that scan for the stock address and hit the management page directly. It is friction, not a fix, but friction against mass scanning is worth having.
Then treat the device as what it is:
- Segment the management plane. Put the router's web UI on a restricted VLAN and limit which hosts can reach it, so a single compromised client cannot walk to the router and use the built-in password.
- Pin trusted DNS downstream. If a hijacked router cannot silently redirect resolution because your endpoints and internal resolvers enforce known-good DNS, you blunt the most useful thing an attacker gets from router admin.
- Inventory and plan replacement. Find every affected model across home-office and branch sites. With no patch coming, replacement, not mitigation, is the endgame. Treat any of these builds as end-of-life the day the advisory dropped.
The broader takeaway outlives this one CVE. When a vendor ships a backdoor and then does not answer, mitigation buys you time and nothing more. The device that cannot be patched and will not be supported is not a device you harden; it is a device you schedule for removal. The routers forwarding traffic at the edges of your network deserve the same scrutiny as the servers at the center, because an attacker who owns the edge does not need the center to hand it to them.