CVE-2026-103530: 9Router SSRF
TL;DR - CVE-2026-103530 is a CVSS 7.3 High server-side request forgery (SSRF) vulnerability affecting decolua 9Router through version 0.5.55. - Restrict the Search Endpoint, control outbound traffic, and block private, loopback, link-local, and cloud metadata destinations. - No confirmed in-the-wild exploitation is reported. Verify the upstream fix and release before considering the vulnerability resolved.
Summary
CVE-2026-103530 is a remotely triggerable server-side request forgery (SSRF) vulnerability in the Search Endpoint of decolua 9Router. The vulnerable path involves the provider_options.baseUrl argument and the fetch function in src/shared/utils/ssrfGuard.js.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-103530 |
| CVSS score | 7.3 High |
| Attack vector | Remote or network-reachable; NVD confirms remote triggering |
| Authentication required | Not established by the available NVD record |
| Affected versions | 9Router up to and including 0.5.55 |
| Patch available | A remediation pull request is referenced, but the fixed release number is not confirmed |
| Vulnerability type | Server-Side Request Forgery, SSRF |
| CISA KEV status | Not listed |
The practical risk depends on where 9Router runs and what its process can reach. A successful SSRF may allow an attacker to probe internal HTTP services, reach administrative interfaces, or request cloud instance metadata. The CVSS score indicates a significant issue, but it does not establish that every deployment has the same internal network exposure.
Root Cause
The vulnerable behavior is associated with server-side URL handling in the Search Endpoint. An attacker-controlled or attacker-influenced provider_options.baseUrl value can affect the destination used by the server-side fetch operation. If destination validation is incomplete, the application may make outbound requests to locations that were not intended as approved providers.
The affected source location identified by NVD is:
src/shared/utils/ssrfGuard.js
The vulnerable element is described as the fetch function. Review the exact corrective code change in upstream pull request #3723. Do not assume that a similarly named local patch or a version above 0.5.55 is sufficient unless the project’s release notes or commit history confirms that the fix is included.
A related upstream issue #3049 discusses SSRF involving /v1/search and provider_options.baseUrl. That report provides defensive context, including internal-port scanning and cloud metadata concerns. It should not be treated as canonical proof that every detail applies identically to CVE-2026-103530.
Who Is Exposed?
The specifically affected product is decolua 9Router, with NVD identifying versions up to and including 0.5.55 as vulnerable. The affected area is the Search Endpoint and its handling of provider_options.baseUrl. Organizations running any release in that range should treat the deployment as exposed until a confirmed fixed release is installed or an effective workaround is in place.
The available records do not establish a separate package identifier, distribution-specific build range, or fixed version number. The project repository is identified as decolua/9router. Deployments built from source, containers, forks, or vendor-maintained packages should be mapped back to the underlying 9Router commit rather than relying only on an externally displayed application version.
Authentication requirements are not conclusively specified in the compact NVD information available for this CVE. A related GitHub report describes a client with a valid API key reaching the affected search path, but that detail should not be generalized into the official CVE’s authentication metric. Review both internet-facing and authenticated internal deployments, especially where API keys are broadly issued.
Severity Breakdown
NVD assigns CVE-2026-103530 a CVSS v3 base score of 7.3, rated High. NVD confirms that the issue can be initiated remotely. However, the retrieved NVD compact record did not expose the complete CVSS vector string, so the individual values for attack complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability cannot be stated reliably.
| CVSS element | Confirmed information |
|---|---|
| Base score | 7.3 |
| Severity | High |
| Remote triggering | Confirmed by NVD |
| Attack vector value | Complete vector unavailable in the reviewed record |
| Privileges required | Not established |
| User interaction | Not established |
| Scope and impact values | Not established |
The score should guide prioritization, not replace deployment analysis. A 9Router process with unrestricted access to cloud metadata, management interfaces, databases, or internal APIs presents greater practical risk than an isolated instance with strict egress filtering. In the absence of a full vector, prioritize internet-reachable 9Router installations and instances that can make arbitrary outbound HTTP or HTTPS requests.
Analyst’s Take: The missing fixed release and incomplete CVSS vector make deployment-level review more important than score-based triage alone. Start with internet-reachable 9Router instances that can make outbound requests, then verify the upstream fix before treating the exposure as resolved.
Exploitation Status
No confirmed exploitation of CVE-2026-103530 in the wild was identified in the reviewed material. The CVE is also not listed in the CISA Known Exploited Vulnerabilities catalog. There is currently no CISA catalog confirmation of active exploitation, a ransomware campaign, or a required KEV remediation deadline.
Public technical activity does exist. NVD references GitHub issue #3714 and pull request #3723, indicating public discussion and remediation work. Related issue #3049 contains an end-to-end report for a related SSRF condition, but the available evidence does not establish a standalone public exploit or weaponized proof of concept specifically for CVE-2026-103530.
The correct operational assumption is not “safe,” but “unconfirmed.” SSRF attacks can be performed with ordinary HTTP clients, so defenders should not wait for a packaged exploit before applying access and egress controls.
Sources
The primary sources for this assessment are the NVD record references associated with CVE-2026-103530 and the decolua/9router repository. The upstream remediation discussion is tracked in pull request #3723, while issue #3714 is also referenced in the public vulnerability material.
Additional technical context appears in related issue #3049. That issue should be read as related research rather than definitive evidence for every CVE detail. The public VulDB CVE page and submission record provide supplementary tracking information.
CISA’s KEV lookup returned on_kev: false for CVE-2026-103530. Because the reviewed data does not provide the complete CVSS vector, confirmed fixed release, or verified exploit-in-the-wild evidence, defenders should recheck the upstream repository, release notes, NVD record, and CISA catalog during remediation.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Start by reviewing requests to the Search Endpoint for unusual provider_options.baseUrl values. Look for destinations using loopback, private, link-local, reserved, or cloud metadata address space, as well as hostnames that resolve to those ranges.
Relevant indicators include:
/v1/searchrequestsprovider_options.baseUrlparameters- Unexpected destination ports
- URL-encoded destination values
- Hostnames resolving to private or link-local addresses
- Repeated requests across many internal addresses
- Outbound connections from the 9Router process that correlate with Search Endpoint activity
Technical Notes
The exact application log format is deployment-dependent. The following searches provide a starting point for common access and application logs:
# Search compressed and uncompressed logs for affected request indicators
grep -RniE '(/v1/search|provider_options\.baseUrl|baseUrl=)' \
/var/log 2>/dev/null
# Identify likely SSRF destinations in captured logs
grep -RniE \
'(127\.0\.0\.1|localhost|169\.254\.169\.254|10\.[0-9]+\.[0-9]+\.[0-9]+|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)' \
/var/log 2>/dev/null
At the network layer, alert when the 9Router process initiates connections to:
127.0.0.0/8- RFC1918 IPv4 ranges
169.254.169.254- IPv6 loopback or link-local addresses
- Unexpected internal ports
- Internal hostnames that are not approved provider destinations
Correlate outbound connection timestamps with inbound Search Endpoint requests and the API identity used. A burst of requests to sequential internal ports is particularly suspicious, but the absence of that pattern does not rule out a single-target SSRF.
Remediation Steps
The affected range is 9Router through 0.5.55. NVD recommends applying the upstream patch, but the available record does not specify the first fixed release. Pull request #3723 is the primary reference for determining the corrected commit and release boundary. Do not document a particular version as fixed until the upstream repository or official release notes confirm it.
After confirming the release that contains the merged fix, upgrade using your organization’s deployment method. For a source checkout, verify the target release or commit before rebuilding:
git fetch --tags origin
git log --oneline --all --grep='CVE-2026-103530\|SSRF' -i
git show <verified-fixed-release-or-commit>
# Rebuild and redeploy only after confirming the fix is included
The placeholder is intentional: the fixed version is not provided in the available advisory data. For container deployments, obtain the image tag that the project explicitly identifies as containing PR #3723, then redeploy and verify the running build rather than assuming latest is patched.
Apply Temporary Compensating Controls
Until the fixed release is verified and deployed:
- Restrict access to the Search Endpoint at the reverse proxy or API gateway.
- Require authentication and authorization for affected routes.
- Allow only approved provider destinations.
- Enforce egress filtering from the 9Router host or container.
- Block loopback, private, link-local, reserved, and cloud metadata addresses.
- Review DNS resolution and prevent DNS rebinding.
- Monitor outbound requests from the 9Router process.
- Rotate exposed API keys if logs indicate suspicious access.
For Kubernetes deployments, combine application controls with a network policy that limits 9Router’s egress to approved destinations. See the guidance on securing inter-pod communication with network policies for additional implementation context.
Technical Notes
A Linux host-level example is:
# Example deny rules; validate interface, chain, and change-control requirements first
sudo iptables -A OUTPUT -d 169.254.169.254 -j REJECT
sudo iptables -A OUTPUT -d 127.0.0.0/8 -j REJECT
sudo iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
sudo iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
sudo iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT
These rules are a workaround, not a substitute for the application fix. Adapt them for IPv6, container networking, cloud security groups, Kubernetes NetworkPolicies, and approved provider exceptions. URL allowlisting should be enforced in addition to IP blocking, with DNS-rebinding protections and destination revalidation immediately before connection.
Also review whether the process can access cloud metadata through alternate addresses or proxy paths. Store API keys and other provider credentials in an approved secrets manager rather than embedding them in configuration files. Teams that need a dedicated credential-management workflow can evaluate Try 1Password →, but the product choice should follow organizational security and compliance requirements.