CVE-2026-55500: Unauthenticated database export and overwrite in 9Router
TL;DR - Critical 9.9 flaw in 9Router before 0.4.80 exposes
/api/settings/database. - Attackers may export secrets or overwrite the full database without proper authentication. - Upgrade to 0.4.80 immediately and review for unauthorized access to the endpoint.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-55500 |
| CVSS Score | 9.9 (Critical) |
| Attack Vector | Network |
| Privileges Required | None clearly required for the exposed action, based on NVD description |
| Patch Available | Yes, fixed in 9Router 0.4.80 |
CVE-2026-55500 is a critical authentication and authorization weakness in 9Router, the decolua project described by NVD as an AI router and token saver. The issue affects the /api/settings/database endpoint, which can be used to export the full database and import a replacement database. According to NVD, exported data may include credentials, API keys, OAuth tokens, and settings.
For defenders, this is not a minor information leak. The exposed functionality touches the entire application database, which means both confidentiality and integrity are at risk. A successful attacker could extract secrets for follow-on compromise or replace stored data to disrupt service, alter routing or settings, or establish persistence through malicious configuration changes.
What Is This Vulnerability?
The root cause, based on the NVD description, is insufficient protection on a highly privileged administrative endpoint. Specifically, 9Router versions prior to 0.4.80 allowed the /api/settings/database endpoint to perform full database export and full database import without a proper authentication requirement beyond an ALWAYS_PROTECTED middleware check. NVD states that this middleware only validates JWT or CLI token, which was not sufficient protection for this operation.
In practice, that means an endpoint capable of disclosing or overwriting the application’s full backing database was not guarded by a strong enough security boundary. This is more severe than a typical missing-auth bug on a low-risk endpoint because the affected action includes full access to stored credentials, API keys, OAuth tokens, and settings, plus the ability to overwrite all of it in one operation.
A defender should think about this in two halves. First, the export path is a secrets exposure event. If an attacker successfully retrieved the database, incident response should assume API credentials and tokens stored in 9Router may be compromised. Second, the import path is a tampering event. If abused, it may let an attacker replace legitimate application data with attacker-controlled content, potentially causing outages, misrouting, privilege changes, or silent persistence.
Technical Notes
The vulnerable path identified by NVD is:
/api/settings/database
The NVD summary states the endpoint permitted:
- full database export
- full database import / complete overwrite
Because the advisory text available in the provided research does not include request samples, defenders should avoid assuming exact HTTP methods or payload formats unless they verify them directly in their deployment or source tree.
Who Is Affected?
The affected product is 9Router from the decolua/9router project. The version range stated in the NVD description is explicit: all versions prior to 0.4.80 are affected. The issue is fixed in version 0.4.80.
If your environment runs 9Router and the deployed version is lower than 0.4.80, you should consider it vulnerable unless you have independently verified that the relevant patch was backported. The available source material for this article does not indicate any alternate fixed branches or backported releases, so the safest assumption is that only 0.4.80 or later remediates the issue.
This also matters for self-hosted and internet-exposed deployments alike. Even if a 9Router instance is intended only for internal use, an internal threat actor, compromised workstation, exposed reverse proxy, or lateral movement path could still abuse the endpoint. If the application is directly reachable from the public internet, the urgency is higher because the attack surface is easier to reach and the impact includes theft of service credentials and OAuth tokens.
Technical Notes
To quickly verify the installed version, check your deployment method first. If you installed from GitHub releases or container artifacts, confirm the exact running tag or binary version rather than relying on documentation or change tickets.
Examples of local verification steps:
# If you manage the app with Docker
docker ps --format 'table {{.Names}} {{.Image}}'
# Inspect a specific container image tag
docker inspect --format='{{.Config.Image}}' <container_name>
# If you deployed from a local checkout
git -C /path/to/9router describe --tags --always
If these checks show any version before 0.4.80, treat the system as affected.
CVSS Score Breakdown
NVD assigns CVSS 9.9, which places this issue in the critical range. The full CVSS vector was not returned in the provided NVD tool response, so defenders should not assume unverified metric values beyond the base score itself. Still, the available facts explain why the score is so high.
The attack is network-reachable because it involves an HTTP endpoint. The impact is broad because the endpoint can expose the full database, including secrets, and also accept a full replacement import. That combination strongly suggests severe confidentiality and integrity impact. Availability impact is also plausible because database overwrite functionality can break application state or render the service inoperable.
What is less certain from the provided data is the exact CVSS metric breakdown, such as user interaction, scope, or the vendor/NVD-selected values for confidentiality, integrity, and availability. In the absence of the published vector string in the source set, defenders should focus on the operational reality: unauthenticated or insufficiently authenticated administrative database operations over the network are emergency patching territory, regardless of the last decimal place in the score.
Technical Notes
Known score data from the research set:
Base score: 9.9
Severity: Critical
CVSS vector: Not returned by the provided NVD tool output
Operationally, treat the vulnerability as:
- remotely reachable
- high-value target due to secret exposure
- high-risk for destructive tampering
Exploitation Status
At the time of writing, active exploitation in the wild is not confirmed by the sources provided for this task. The research note states that CISA KEV status is false, meaning CVE-2026-55500 is not listed in the CISA Known Exploited Vulnerabilities catalog at lookup time. That means there is no CISA-backed confirmation here of known in-the-wild exploitation.
Likewise, the provided source set does not identify a separate public proof-of-concept repository. There is an official GitHub Security Advisory reference and a patch commit, but that is not the same as a weaponized exploit or a confirmed public PoC. Defenders should therefore state the status carefully: no confirmed in-the-wild exploitation from KEV, and no separate public PoC identified in the provided research set.
That said, absence of evidence is not evidence of safety. The vulnerable operation is straightforward to understand from the description, the affected endpoint is named, and a patch commit exists. That means reproducing the issue may be feasible for attackers or researchers even if no packaged PoC has been widely circulated yet. Security teams should prioritize patching based on impact and exploitability characteristics, not on KEV inclusion alone.
Technical Notes
Current exploitation status from the provided sources:
CISA KEV listed: No
Public PoC identified in provided research: No separate PoC identified
In-the-wild exploitation: Not confirmed by provided sources
Defensive assumption if visibility is limited:
Assume opportunistic probing is possible once the endpoint and fixed version are public.
How to Detect It
Detection should focus on requests to /api/settings/database, especially any successful access from unusual sources, unauthenticated sessions, unexpected automation, or administrative actions outside normal change windows. Because the vulnerable behavior includes both export and import, defenders should look for large response bodies leaving the application and suspicious write operations that correlate with configuration drift, service errors, or sudden changes in stored settings.
If you have reverse proxy logs, API gateway telemetry, WAF logs, or application access logs, start by identifying every request to the endpoint over your retention period. Pay close attention to requests originating from internet IPs, cloud VPS ranges, scanning infrastructure, or internal hosts that do not normally administer 9Router. If you lack detailed app logs, use network telemetry to identify connections to the 9Router service around known admin paths and correlate them with spikes in outbound transfer volume or subsequent authentication failures to integrated services.
Technical Notes
Concrete log pattern to hunt for:
/api/settings/database
Example grep against access logs:
grep -R "/api/settings/database" /var/log/nginx/ /var/log/apache2/ /var/log/9router/ 2>/dev/null
Example generic web log query logic:
url.path="/api/settings/database"
Example Splunk search:
index=web OR index=proxy
"/api/settings/database"
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, http_method, status, user_agent, host
| sort - count
Example Elastic/Kibana KQL:
url.path : "/api/settings/database"
Example Sigma-style idea for reverse proxy logs:
title: 9Router Database Settings Endpoint Access
logsource:
category: webserver
detection:
selection:
cs-uri-stem: "/api/settings/database"
condition: selection
level: high
Also investigate for follow-on indicators after suspected export or import activity:
- sudden changes to application settings
- unexpected OAuth token failures or API key misuse
- new outbound API activity using stored credentials
- service instability after a suspected database import
Mitigation and Patching
The primary remediation is to upgrade 9Router to version 0.4.80 or later. The research note is explicit that versions prior to 0.4.80 are affected and 0.4.80 contains the fix. If you operate multiple 9Router instances, validate each one individually. Do not assume that staging, development, or sidecar instances are harmless, since all may contain usable API keys, OAuth tokens, or other sensitive settings.
After patching, rotate any credentials that may have been stored in the application if you have evidence, or even reasonable suspicion, of unauthorized access. Because the vulnerable endpoint could disclose the full database, incident response should consider credentials, API keys, OAuth tokens, and configuration secrets potentially exposed. If you suspect database import abuse, also verify application integrity and compare known-good configuration backups against the current state.
If you cannot patch immediately, place the service behind a trusted access boundary as a temporary containment measure. Restrict access to the 9Router management surface using a reverse proxy allowlist, VPN-only access, private network segmentation, or equivalent controls. This is a stopgap, not a substitute for upgrading, because the issue affects a privileged endpoint and compensating controls can fail or be bypassed through other misconfigurations.
Technical Notes
Specific version target:
Upgrade to 9Router v0.4.80 or later.
Affected: all versions prior to 0.4.80
Fixed: 0.4.80
Example upgrade workflow for a Git-based deployment:
cd /opt/9router
git fetch --tags
git checkout v0.4.80
# follow your normal build/restart procedure after checkout
Example Docker-style update pattern, if your deployment uses container tags that mirror release versions:
docker pull decolua/9router:v0.4.80
docker stop 9router
docker rm 9router
docker run -d --name 9router decolua/9router:v0.4.80
If your environment uses Docker Compose:
# Update the image tag in compose.yaml to v0.4.80, then:
docker compose pull
docker compose up -d
Temporary reverse proxy restriction example with NGINX allowlisting:
location /api/settings/database {
allow 10.0.0.0/8;
allow 192.168.0.0/16;
deny all;
proxy_pass http://9router_backend;
}
Post-patch validation steps:
# Confirm endpoint access is appropriately restricted in your environment
curl -i https://<9router-host>/api/settings/database
If compromise is suspected, prioritize secret rotation:
- rotate API keys stored in 9Router
- revoke and reissue OAuth tokens where possible
- reset service credentials exposed through the database
- audit downstream services for misuse of those credentials
References
The primary authoritative source for the vulnerability is the NVD record, which describes the affected endpoint, impact, and fixed version. The patch commit and release page are the best references for remediation tracking, while the GitHub Security Advisory may provide additional vendor-side context as it is updated.
Because some source pages may evolve after publication, defenders should preserve copies of advisories, patch notes, and internal detection findings in their ticketing or incident systems. For environment-specific decisions, always validate against the running deployment rather than relying only on package manifests or stale inventory.
- NVD CVE record: https://nvd.nist.gov/vuln/detail/CVE-2026-55500
- Official patch commit: https://github.com/decolua/9router/commit/0c7c9de00ae3ab81d6580e3cc368483c4c03f6fd
- Fixed release v0.4.80: https://github.com/decolua/9router/releases/tag/v0.4.80
- GitHub Security Advisory: https://github.com/decolua/9router/security/advisories/GHSA-qvfm-67h2-2qfx
- Official repository: https://github.com/decolua/9router
- Official website: https://9router.com
If you are triaging this in production, the immediate actions are straightforward: identify any 9Router instances below 0.4.80, restrict access if you cannot patch right away, upgrade to 0.4.80, hunt for requests to /api/settings/database, and rotate any secrets that may have been exposed.
For more information on securing your network, check out our articles on what is privileged access management and how to secure my home Wi-Fi network.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.