9Router default password 123456 (CVE-2026-63732): server takeover risk

A flaw has been disclosed in "9Router," the popular free tool that routes coding tools like Claude Code, Cursor, and Cline across multiple AI services, that lets anyone log in with the default password "123456" and go on to take over the server. It is CVE-2026-63732, rated 9.9 out of 10. It is the seventh serious flaw covered in this article, following the six already documented here.

What makes it nasty is that "123456" was written directly into the program. Anyone who reads the source code learns it, and unless the operator sets a password themselves, the same value works on every 9Router instance in the world. And the flaw does not stand alone: it is a chain in which that one shared secret becomes the entrance to features that are supposed to be reachable only from the machine in front of you. The destination is attacker-supplied commands running on your server.

There is a second fact that matters just as much to readers. The version that public databases name as the fix, 0.4.60, was never actually released. Cross-checking the npm publish record against the GitHub release list, we found that the version after 0.4.59 is 0.4.62. In other words, the instruction "upgrade to 0.4.60" cannot be carried out as written. To put the conclusion first: go to the latest version available on npm, 0.5.40 (published July 20, 2026), and set a dashboard password yourself.

Note also that real-world attacks have already been observed against this product. For a separate flaw that lets an attacker take over the server with no login (CVE-2026-59800, severity 9.8), the monitoring group Shadowserver Foundation reports observing exploitation on July 4, 2026. If you are running an old version exposed to the internet, update it and stop exposing it before reading any further.

The default password was "123456": an overview of CVE-2026-63732

First, the substance of the newly disclosed item. 9Router has an administrative screen (a dashboard), and the operator sets a password to get into it. The problem was that when the operator has not set one yet, the string "123456" written into the program is accepted as correct. An instance that was installed and left untouched was, by that very fact, an instance anyone could log into.

A hardcoded default password is one of the uglier kinds of vulnerability. Anyone who reads the program learns the value. The same value works on every instance until it is changed. And operators find it hard to notice they are in that state. Those three things stack. This time the word "chain" is attached as well, meaning the shared secret alone would not get you far, but it becomes the starting point that gets you the rest of the way. The next section takes it apart.

There are people out there hunting for "123456"

The people most delighted by machines on the internet that open to "123456" are those collecting keys so they can run their AI usage on someone else's account, and intruders who use a developer's PC or server as a stepping stone into a company network. No sophistication is required. It is enough to hammer away at addresses across the internet and find the machines left at the default. That kind of sweeping is not done by hand; programs do it on a loop.

Log into the dashboard with "123456," then lie about where the request is addressed in order to call features meant only for the local machine, and finally register a doctored command through the AI tool integration and have it run on the server — three moves, run the moment a scan turns up a machine. The vendor's own page publishes steps that carry out all three. With the material for an attempt fully assembled, this is not a situation that waits for you.

Once the API keys you piled into one place are in someone else's hands, what follows depends on who you are. An individual using 9Router has the keys to their AI services carried off and gets billed for usage they never incurred. An organization running it finds that one machine becomes the doorway into the internal network. Because 9Router holds keys for several AI services in one place, breaking a single instance tends to cost a lot. The pattern of spreading into an organization through development tools and relay software is the same one behind the takeover vulnerability in the relay tool LiteLLM, and from the standpoint of auditing the OSS supply chain, relay tools like this deserve to be looked at first.

What is happening technically in CVE-2026-63732

The vendor's advisory (GHSA-4922-8r65-fq26) describes this item as a combination of three independent flaws. We take them in order, then look at why the severity jumps when all three are present.

CVE-2026-63732: from the default password "123456" to server takeover in three moves (severity 9.9)

The first is the default password itself. The login handler in src/app/api/auth/login/route.js, when no password is stored in the database, compares the input against the environment variable INITIAL_PASSWORD or, failing that, the string "123456". On an instance that was merely installed and started, there is no stored password, so sending "123456" gets you a genuine login cookie. In the classification maintained by the U.S. National Institute of Standards and Technology (NIST), this is use of default credentials (CWE-1392).

The second is the test for "is this request local?" 9Router keeps a list of dangerous features that are, in principle, callable only from the machine running 9Router. But the test that enforced it, isLocalRequest() in src/dashboardGuard.js, at the time only looked at whether the Host label sent with the request said localhost. That label is written freely by whoever sends the request, so simply sending Host: localhost:20128 from far away passes as "local" (authentication bypass by spoofing, CWE-290).

The third is MCP plugin registration for AI tool integration. The "program to run" that you may specify at registration is restricted to an allowlist such as node and python, yet the "arguments" handed to that program were not checked at all. Since node is allowed, lining up -e plus an arbitrary program in the arguments gets it executed straight through child_process.spawn() (command execution, CWE-78).

Connect the three in order and it is over in three moves. (1) Log in with "123456" and get a cookie. (2) Lie about the Host label to reach the local-only registration endpoint and register a plugin carrying your command. (3) Hit that plugin's notification endpoint (SSE) to make it run. No click from the legitimate operator is needed. The commands run with the privileges of the user running 9Router, which the vendor notes can be administrator (root) in Docker deployments.

Also impossible to overlook: once that second gate is broken, other dangerous endpoints open at the same time. The vendor names them specifically.

So this is not only about running commands: the wiring of your AI conversations can be switched so that everything passes through someone watching from the side. Takeovers that enter through the AI integration layer (MCP) repeat the same shape seen in the MCP server for Kubernetes operations and in mcp-pinot, where tools could be invoked without authentication.

Where the numbers and the prose disagree (a note against overstating it)

The published material on this item is not internally consistent. Three points to keep in mind. First, the treatment of "is authentication required?" NVD's description says "a remote, unauthenticated attacker," yet the severity formula (the vector) says PR:L, meaning low privileges are required. The vendor advisory is titled "Authenticated Remote Code Execution." Rather than one being right, logging in with a default password merely counts formally as "authentication"; since that password is a public value, in practice it reads as close to unauthenticated.

Second, the affected range. The vendor lists only the single version 0.4.59, while NVD and VulnCheck say "everything before 0.4.60." The default-password handling had been present in older versions, so the latter is closer to reality — but reading only the vendor's wording invites the misreading "we're not on 0.4.5x, so this doesn't apply to us." Third, the classification (CWE). The vendor lists three (CWE-78, CWE-290, CWE-1392), while NVD carries only CWE-78. The one that best captures the character of this item is CWE-1392 for the default password, so reading NVD alone loses the point.

Note that this CVE's status at NVD is "Deferred," and neither the 9.9 nor the 9.4 is a score NVD assigned itself; both come from VulnCheck, which assigned the CVE ID. The U.S. CISA assessment (SSVC) as of July 27 records "exploitation: none," "automatable: no," and "technical impact: total."

"Fixed in 0.4.60" was never released (verified here)

NVD, VulnCheck, and the vendor advisory all say "fixed in 0.4.60." But you cannot actually obtain that 0.4.60. Here is what we checked.

• The npm publish record (registry.npmjs.org/9router) has no 0.4.60 and no publish date for it. The version after 0.4.59 (May 21, 2026) is 0.4.62 (May 26)
• There is no v0.4.60 tag or release on GitHub either; v0.4.62 is the next published version
• This is not a one-off. 0.4.72 and 0.4.82, named as fix versions in other advisories, do not exist on npm or GitHub either
• Other versions disagree between the two sources. 0.4.44 and 0.5.6 have GitHub tags but are absent from npm, while 0.4.45 is on npm but has no GitHub tag

In short, for this product the fix version numbers written in the advisories frequently do not match what you can actually install. The ordinary remedy of "upgrade to the version they specified" does not go through as written. That is exactly why aiming at the latest release becomes the practical policy.

More important still, going to 0.4.62 does not close this chain. For the second link (Host spoofing) and the third (unvalidated plugin arguments), the vendor itself says "fixed in 0.5.2" in a separate advisory (GHSA-63p9-g54h-prrp / CVE-2026-62312). Two fix versions, "0.4.60" and "0.5.2," coexist for the same defect, and the latter is the one that actually shipped.

"123456" is still there in the latest version (why updating is not enough)

This is the finding that changes what you actually have to do. Reading the login handler in the latest 0.5.40, the line that accepts 123456 when no password is set is still there. What 0.4.80 added was only a piece of logic that attaches a mustChangePassword field to the response. And that field appears only when three conditions coincide — no stored password, no environment variable, and a request from somewhere other than the local machine — and even then, the login itself succeeds and the auth cookie is issued first. It is a mechanism for prompting "please change your password" on screen, not one that closes the door.

The second item, the "is this local?" test, has been rebuilt. In the 0.5.40 logic, the anchor is no longer the Host label but a value the server writes itself from the connecting IP address, and if a proxy hop is detected the request is judged "not local". That spot did not get fixed in one pass, though. CVE-2026-49353 called the previous fix incomplete, and it was patched again for CVE-2026-55641 (fix 0.4.82), CVE-2026-56675 (fix 0.5.2), and CVE-2026-56681 (fix 0.5.6), the last of these abusing the X-9r-Real-Ip label that the rebuild itself introduced.

So "update to the latest version" is not sufficient on its own. After updating, be sure to set the dashboard password yourself. If you do not, "123456" still works even on the latest version.

What 9Router is, and how widely it is used

9Router is a routing proxy that sits between "AI tools that write code for you" — Claude Code, Cursor, Cline, Copilot — and the AI services that power them behind the scenes (Claude, GPT, Gemini, and 40-plus more). When you hit a usage limit it automatically switches to another free or cheap service, and it compresses the data being sent to cut consumption, promising to let you "use AI coding heavily for free or at low cost." It is free, MIT-licensed software that users run on their own PC or server.

The flip side of that convenience is that 9Router stores the API keys (secret keys for using each service) and the OAuth login-linking tokens for the AI services it connects to, all together in its own database. If that is broken into, keys for multiple services leak at once. Relay software that manages many AIs becoming a target is a pattern seen again and again, as with the takeover vulnerability in the similar relay tool LiteLLM and the API-key bypass flaw in the AI platform vLLM.

On scale, we will be straight. GitHub stars sit at roughly 24,000 (as of July 29, 2026), which is fast growth for a project first published in January 2026. But a star count is "people who were curious," not instances in operation. Japanese-language write-ups are almost nowhere to be found, and we could not confirm signs of broad business use in Japan. This is not the kind of story where an entire country is affected, as with a corporate core system. Even so, for the people who do use it, the keys to every service they entrusted to it are all put at risk together. The realistic picture is individual development environments and small teams that installed it to save on AI bills.

The six vulnerabilities disclosed earlier

From here on are the six items this article has covered so far. They have moved down in order, but the content is unchanged. If you arrived by searching a CVE number, this is the section to read.

CVE-2026-59800: server takeover without login, real attacks observed (severity 9.8)

Among this product's vulnerabilities, this is the one for which real-world attacks have already been confirmed. 9Router has an endpoint, /api/tunnel/tailscale-install, for installing the internal-network service "Tailscale." But this endpoint was built to run the values it received as commands on the server, without requiring any login at all. An attacker only has to send one crafted web request here to run arbitrary commands on the server without authentication (OS command injection, CWE-78). The severity is 9.8 under CVSS 3.1 and 9.2 under 4.0. Affected are versions before v0.4.44, and it is fixed in v0.4.44. The Shadowserver Foundation reports observing real-world exploitation of this flaw on July 4, 2026, showing that internet-exposed 9Router instances have become targets of automated scanning.

CVE-2026-55500: the whole database can be exported, leaking every key (severity 9.9)

9Router has a settings endpoint at /api/settings/database that allows exporting and importing the database. The problem is that the mechanism guarding this endpoint only checked "whether a token is present," not "whether this party is allowed to perform a sensitive operation." As a result, even a low-privilege user can export the entire database, including API keys, OAuth tokens, and OIDC secrets in plaintext. The import side is unguarded too, so an attacker can overwrite the whole database with contents of their choosing. NIST classifies this as exposure of sensitive information (CWE-200). Affected are versions up to v0.4.71, and NVD cites v0.4.80 as the fix in the vendor's response.

CVE-2026-46339: command execution on the server without any login (maximum rating 10.0)

9Router has endpoints such as /api/cli-tools/ and /api/mcp/ for integrating with external tools. However, the login-requiring mechanism only protected eight predetermined endpoints, leaving these integration endpoints unguarded. Without logging in, an attacker can register a malicious "plugin" (an extension carrying arbitrary commands) and simply call another endpoint to run commands freely on the server. The severity reaches the CVSS ceiling of 10.0. Affected are v0.4.30 through v0.4.36 — a flaw introduced when the external-integration (MCP) feature was added — and it is fixed in v0.4.37. Requiring neither login nor user action, it is the most easily exploited type.

CVE-2026-49352: authentication bypassed with a hardcoded shared secret (severity 9.8, public PoC)

9Router signs the token that proves your login state with a secret phrase (a JWT secret). The problem is that if a user has not set this phrase themselves, a default phrase embedded directly in the program, "9router-default-secret-change-me," is used as-is. Because anyone can learn this string, an attacker can use it to forge a legitimate login token themselves and freely access the dashboard and API. NIST classifies this as use of hardcoded credentials (CWE-798). Affected are v0.2.21 through v0.4.44, and it was fixed in v0.4.45. A proof of concept has already been published, and an older version that leaves this phrase in place can, combined with the database export (55500), have all its keys extracted effectively without any login. CVE-2026-63732 is the "default password"; this one is the "default signing key." The same product has repeated the same class of mistake — leaving a default value embedded — twice.

CVE-2026-62312: after authentication, Host spoofing plus plugin arguments yield command execution (severity 8.8)

A two-stage trick: spoof the "Host header" that names the destination to reach an endpoint that should be local-only, then get to command execution through unvalidated plugin arguments. As a flaw exploitable by an authenticated user, it is rated 8.8 and said to be fixed in v0.5.2. CVE-2026-63732 adds one step in front of these two — being able to log in with the default password — and as a result the premise that "only an authenticated user can use it" collapses, pushing the severity from 8.8 up to 9.9. The reporter is the same darealDanh, and the vendor advisories were published in close succession on July 3 and July 10.

CVE-2026-55501: bypassing the limit on login attempts (severity 7.3)

The dashboard's limit on login attempts judged the client's identity from X-Forwarded-For, a label the sender can write freely, so simply changing the value each time yielded a fresh limit bucket, nullifying the lockout that should stop you after five tries and allowing unlimited password guessing. Affected are versions before v0.4.80, and it was fixed in v0.4.80. Its standalone severity is 7.3, but a state where passwords can be guessed endlessly works differently once combined with the default-password problem.

So which version do you have to reach to close everything

The answer fits in one line: go to the latest version available on npm, 0.5.40 (published July 20, 2026), and then set a password yourself. The reason is that the fix versions for the seven items are scattered, and among the published fix versions, 0.4.60, 0.4.44, and 0.5.6 cannot be obtained from npm. Since some of them cannot be installed as specified, aiming at the latest release is more reliable than chasing each one.

The rightmost column, "what you actually get on npm," is our own addition after cross-checking the npm publish record against GitHub tags. CVE-2026-59800's fix is published as 0.4.44; GitHub has a v0.4.44 tag but npm has no 0.4.44, so from npm the first fixed version is 0.4.45. Conversely, CVE-2026-49352's fix 0.4.45 is on npm but has no GitHub tag. Specifying the published number does not always give you something installable, so use this column as your guide. For CVE-2026-63732, the default password itself remains in the latest version, so upgrading is not enough: setting a password is the substance of the fix.

The seven items covered here are a subset of the advisories the vendor publishes on GitHub. That page lists 19 as of July 29, 2026, including some whose fix versions are given as 0.5.4 or 0.5.6. The reason to aim at the latest release is that even these seven do not cover it.

Registration status in Japan, and signs of exploitation

We checked how public bodies in Japan are handling this. The vulnerability database JVN iPedia has not registered a single 9Router vulnerability, CVE-2026-63732 included (a keyword search returns zero hits). No advisories have been issued by JPCERT/CC or IPA either. We found no Japanese-language reporting or technical write-ups, so for CVE-2026-63732 at least, this appears to be the first substantial coverage in Japanese.

We also looked at the indicators for likelihood of exploitation. EPSS (an estimate of the probability of exploitation in the next 30 days) stood at 0.74% on July 28, roughly the middle of all CVEs (51st percentile). The highest within this product is CVE-2026-46339 at 2.40%, and CVE-2026-59800, which has actually been exploited, sits at 1.34%. Even the confirmed-exploited CVE-2026-59800 stays in the 1% range, so for this product the indicator has not caught up with reality. Do not treat the low number as reassurance. The U.S. CISA Known Exploited Vulnerabilities catalog lists no 9Router vulnerability as of the July 27 edition (1,655 entries). You can check the current KEV status on our dashboard.

This is the writer's own view, but we expect more CVEs from this product. Two reasons. One is how this seventh item surfaced late. The vendor advisory was published on July 3, yet the CVE ID was assigned on July 23 — and assigned not by the vendor or GitHub but by a separate organization, VulnCheck. The GitHub advisory still has no CVE ID attached. Given that an ID demonstrably arrived later through a different route, it is more natural to assume other disclosed-but-unnumbered items remain. The other is that the same place — the test for "is this local?" — has been patched over and over, with a new flaw appearing each time. Read this paragraph as an assessment rather than as fact.

What we corroborated, and what stays unverified

Update to 0.5.40 — and set the password yourself

There are three things. First, update to the latest version available on npm (0.5.40). The fix versions for the seven items are scattered, and 0.4.60, 0.4.44, and 0.5.6 cannot be obtained from npm, so aiming at the latest is more reliable than chasing each one. Second, set the dashboard password yourself. This is the substance of the fix here. Leave it unset and "123456" still works even on the latest version. Third, stop exposing it to the internet. If you use a tunnel, a VPS deployment, or cloud sync, take it off. 9Router is meant to run only in your own environment, and the more you open it up, the more holes like these get hit.

In addition, if there was any period when you exposed an old version, finish rotating (reissuing) the API keys and tokens you had stored. You cannot rule out that they have already been taken. Recreate the keys in each AI service's console and revoke the old ones. Entrusting keys to a relay tool is convenient, but the fact that damage spreads all at once when the custodian is breached is shared with vulnerabilities that leak credentials in an HTTP library and the API-key theft vulnerability in the AI coding tool Cline.

Frequently asked questions

Summary

The newly disclosed CVE-2026-63732 is about 9Router, the popular relay tool for using AI coding cheaply, having the default password "123456" written into the program. Severity 9.9. From that one shared secret, lying about where a request is addressed reaches local-only features, and plugin registration in the AI tool integration reaches command execution — three moves, connected. Reproduction steps are public too.

The practical conclusions for readers are two. One: the published fix 0.4.60 does not exist, so go to npm's latest 0.5.40. Two: "123456" is still in the latest version, so separately from updating, set a password yourself. Along with that, stop exposing it to the internet, and if there was a period of external exposure, recreate your API keys. In this product, real exploitation has also been observed for a different flaw (CVE-2026-59800).

The convenience of entrusting keys for several AI services to one place comes inseparably with the hazard that damage concentrates when the custodian is breached. Beyond 9Router, if you stand up your own relay for AI, it is safer to assume from the outset that the one machine is a keyring. If new CVEs are disclosed or exploitation moves, we will add to this article.

Update history

References

• ▸ NVD - CVE-2026-63732 (chain from the default password, added now)
• ▸ GitHub Security Advisory - GHSA-4922-8r65-fq26 (CVE-2026-63732, with reproduction steps)
• ▸ VulnCheck - 9router before 0.4.60 Remote Code Execution via default password
• ▸ 9Router published advisories (GitHub; 19 as of July 29, 2026)
• ▸ npm registry publish record (confirming 0.4.60 does not exist)
• ▸ 9Router releases (GitHub)
• ▸ Login handler in the latest 0.5.40 (the "123456" line remains)
• ▸ Local-request check in the latest 0.5.40 (from Host-based to peer-IP-based)
• ▸ GitHub Security Advisory - GHSA-63p9-g54h-prrp (CVE-2026-62312, fixed in 0.5.2)
• ▸ NVD - CVE-2026-55500
• ▸ GitHub Security Advisory - GHSA-qvfm-67h2-2qfx (CVE-2026-55500)
• ▸ GitHub Security Advisory - GHSA-fhh6-4qxv-rpqj (CVE-2026-46339)
• ▸ NVD - CVE-2026-59800 (unauthenticated RCE; exploitation observed by Shadowserver)
• ▸ NVD - CVE-2026-55501 (login attempt limit bypass)
• ▸ GitLab Advisory - CVE-2026-49352 (default JWT secret)
• ▸ CISA Known Exploited Vulnerabilities Catalog (9Router not listed)
• ▸ FIRST EPSS (estimated exploitation probability)
• ▸ JVN iPedia (no 9Router entries)
• ▸ 9Router official repository (GitHub)