Six vendors, six unrelated products, one root cause. Since July, SolarWinds Access Rights Manager, Cisco Secure Firewall Management Center, ASUS Control Center Enterprise, Dell Secure Connect Gateway, ManageEngine Applications Manager, and Tenda’s consumer router line have all disclosed vulnerabilities that trace to the exact same design failure: a credential, cryptographic key, or password that was supposed to be unique per deployment and instead was baked into the shipped software, identical on every copy, in every customer’s environment, forever — or at least until someone bothers to patch. CISA’s KEV catalog already has one of these under active exploitation. At least two more are chained into full unauthenticated-to-root compromises. None of them are exotic. CWE-798 (Use of Hard-coded Credentials) and its sibling CWE-321 (Use of a Hard-coded Cryptographic Key) have been in MITRE’s top-25 most dangerous weaknesses for over a decade. Every SAST scanner flags them. Every secure-coding course covers them. And in 2026, they’re still how attackers get root on the platforms that manage everything else.

This isn’t a story about sloppy junior developers leaving a password in a config file. Every example below shipped in commercial, security-relevant, often security-branded software from vendors with mature SDLC programs. That’s the actual finding: hardcoded secrets survive code review, survive pen tests, survive years of production deployment, because they don’t look like bugs from the inside. They look like a working feature. The bug only becomes visible from the outside, once, and then it’s visible in every single deployment simultaneously.

The corpus: six failures, one shape

SolarWinds Access Rights Manager — CVE-2026-28326 (CVSS 8.8). ARM’s internal components talk to each other over an RPC interface secured by a cryptographic key that’s supposed to be generated per install. It isn’t — the key is baked into the shipped binaries, identical across every ARM deployment on earth. Extract it once from any copy of the commercially available software, and you can forge the token that lets you talk to the backend as a trusted internal component. No credentials, no user interaction, just network reachability to a product whose entire job is auditing who has access to Active Directory, Exchange, and file servers. SolarWinds shipped an out-of-band fix in ARM 2026.2.1 on September 17.

ManageEngine Applications Manager — CVE-2026-86708 (CVSS 10.0). This one isn’t even a logic bug — it’s a packaging failure. Zoho’s Linux installer for Applications Manager shipped with a live Google Cloud service-account private key embedded directly in the archive, over-privileged relative to what the installer actually needed. Anyone who downloaded the public installer — which is, by definition, everyone who ever evaluated the product — could unzip their way to a working GCP credential. Rotating the key stops future abuse; it does nothing for whoever already extracted and archived it during however long that installer sat public.

ASUS Control Center Enterprise — CVE-2026-75754 (CVSS 10.0). A three-step chain: an unauthenticated endpoint leaks the instance’s internal encryption key, that key triggers a local service to open SSH on port 2222, and a hardcoded credential baked into the product authenticates to that listener for a root shell. Three separate design decisions, each individually indefensible, stacked into a fully unauthenticated root compromise of a fleet-management console with privileged reach into every endpoint it manages.

Cisco Secure Firewall Management Center — CVE-2026-20316 (CWE-798, CISA KEV). A low-privilege service account with a static, hardcoded password baked into the FMC web UI. Cisco initially scored it a modest 5.3 — it’s “only” a low-privilege account — until you notice that CISA added it to the Known Exploited Vulnerabilities catalog the same day Cisco disclosed it, and Cisco’s own advisory flags it as a chaining primitive toward deeper compromise. Attackers didn’t need the vulnerability to be severe on its own. They needed it to be a working front door.

Dell Secure Connect Gateway — CVE-2026-80170, chained with CVE-2026-80172, -61410, and -80238. A hardcoded-credential bypass sits alongside a token-replay flaw, a missing-authorization RCE, and an exposed Docker socket — four bugs that chain into unauthenticated root on an appliance Dell specifically designs to maintain trusted outbound connectivity from customer networks into Dell’s support infrastructure. The hardcoded credential isn’t even the most severe bug in the chain (CVSS 9.8 goes to the token-replay issue). It’s just one more door that didn’t need a key.

Tenda router firmware — CVE-2026-11405, no patch available. The outlier, and the most instructive one. This isn’t an accidental leftover — CERT/CC’s analysis of /bin/httpd shows a deliberately built second authentication path: if the real password check fails, the login function falls through to a plaintext comparison against a value read from sys.rzadmin.password, and any username is accepted alongside it. That’s not a mistake that survives code review by accident. Someone wrote that fallback on purpose, it shipped across at least five firmware builds and four product lines, and CERT/CC got no response from Tenda after first contact in May. There is still no fix.

Why this keeps happening

Line up the six and a pattern falls out that has nothing to do with any individual vendor’s competence:

Hardcoded secrets are load-bearing during development, and nobody circles back. A shared key makes internal RPC “just work” across every dev and test environment without a provisioning step. A bundled service-account key makes the installer’s cloud integration testable without asking every engineer to mint their own credentials. These aren’t malicious shortcuts — they’re the path of least resistance during development, and the ticket to replace them with per-install generation competes against feature work for every subsequent release cycle. It loses, repeatedly, until an external researcher finds it.

The failure mode is binary, not gradual. A SQL injection bug might be exploitable in one query and not another, might need specific input encoding, might vary by database backend. A hardcoded key is either extractable or it isn’t, and once it’s extractable from one copy, it’s valid against every copy. There’s no long tail of partial exploitability to buy defenders time — Kai Huang didn’t need SolarWinds ARM in a specific configuration, just a copy of the software. Fox-IT’s team famously found Juniper’s ScreenOS backdoor password (CVE-2015-7755 — the literal string <<< %s(un='%s') = %u, chosen to blend in with debug format strings) within six hours of starting to look, and a subsequent Shodan sweep found roughly 26,000 internet-facing NetScreen devices with SSH open to receive it. Extraction difficulty is not where this bug class gets you.

It hides specifically from the tools built to catch it. Static analysis flags a hardcoded string literal used as a credential — but not a key derived at build time and injected into a binary, not a credential shipped inside an installer archive rather than the application code, not a fallback authentication path that only activates when the primary check fails. Pen testers rarely get a copy of the installer to reverse-engineer; they get network access to a running instance, which is exactly the threat model where a well-hidden hardcoded secret looks indistinguishable from properly implemented auth, right up until someone pulls the binary apart. ManageEngine’s flaw wasn’t in the application at all — it was in the release artifact. That’s a blind spot most AppSec programs don’t even have a gate for, because “installer packaging” and “source code” answer to different owners.

Management-plane software makes the blast radius worst-case by construction. Every one of these six products exists specifically to hold privileged, centralized reach across an environment — that’s the entire value proposition of ARM, FMC, ACC, and SCG. A hardcoded secret in a leaf-node application is bad. A hardcoded secret in the system that was bought specifically because it has domain-admin-adjacent rights over everything else is a single extraction away from the whole estate. This is the same convergence covered here before with Cisco FMC’s repeat zero-days: concentrating privilege into one console doesn’t just centralize administration, it centralizes the payoff for finding one bug.

What actually stops this

Patching each CVE as it lands is necessary and not remotely sufficient — you’re playing whack-a-mole against a bug class, not a bug. Three controls actually change your exposure:

Segment management interfaces as if they’re the crown jewels, because they are. Every incident above assumes network reachability to a management-plane service as the entire prerequisite. ARM, FMC, ACC, and SCG should sit on isolated management VLANs reachable only from a small, enumerated set of admin workstations and jump hosts — not “the internal network,” which in most environments means every laptop, VPN client, and compromised endpoint that’s ever touched it. This single control neutralizes CVE-2026-28326, CVE-2026-75754, and CVE-2026-20316 without waiting on a vendor patch, because “adjacent network” and “management interface reachable” are doing all the work in each CVSS vector.

Treat every vendor installer, OVA, and container image as untrusted until you’ve scanned it — not just the source repo you don’t have. Run trufflehog, gitleaks, or equivalent secret-scanning against extracted installer contents, firmware images, and container filesystems before they land in a golden image or internal mirror, the same way you’d scan a third-party dependency. ManageEngine’s flaw would have been caught by anyone who ran secret-scanning against the installer artifact instead of assuming vendor-shipped binaries are opaque and trusted by default. This is cheap, it’s automatable in a CI step ahead of internal repackaging, and almost nobody does it for vendor software the way they’ve started doing it for their own build pipelines.

Assume every “static” credential is compromised the moment it’s disclosed, and rotate what it touches — not just the credential itself. ManageEngine rotated the GCP key; that doesn’t retroactively secure whatever an attacker already reached with it before disclosure. When a hardcoded secret comes out, the remediation isn’t “patch and move on” — it’s patch, rotate every downstream credential and permission grant the compromised secret could have reached, and audit logs for the account or service the secret authenticated as, going back as far as retention allows. Cisco’s own advisory for CVE-2026-20316 makes this explicit: the low-privilege account is dangerous specifically because of what it can be chained into, not what it does alone. Treat the disclosure date as your minimum look-back window, not your starting point for cleanup.

The takeaway

CWE-798 isn’t a legacy problem that better tooling solved a decade ago — it’s a structural incentive problem that better tooling hasn’t touched, because the tooling looks for string literals and the failures increasingly live in installers, firmware images, and build artifacts instead. Six vendors, six product categories, one root cause, all in a single quarter. If you run management-plane software of any kind — and if you’re reading this, you do — the question isn’t whether one of your vendors has a hardcoded secret sitting in production right now. It’s whether your network segmentation and your monitoring would notice before the vendor’s advisory does.