CVE-2026-30858: Server-Side Request Forgery via DNS Rebinding in Tencent WeKnora

Tencent WeKnora is an LLM-powered framework designed for deep document understanding and semantic retrieval. The application includes a web_fetch tool that enables agents to retrieve external web content for processing. This tool accepts user-provided URLs and fetches the target content using the chromedp headless browser library.

Versions of WeKnora prior to 0.3.0 suffer from a Server-Side Request Forgery (SSRF) vulnerability. The implementation fails to properly pin resolved IP addresses during the content fetching process. This architectural flaw permits an external attacker to bypass the application's internal security controls.

The vulnerability is classified as an unauthenticated attack vector. An attacker can supply a crafted hostname that circumvents input validation, causing the server to issue HTTP requests to restricted internal network segments. This exposes internal services hosted on private IP addresses, such as 127.0.0.1 and 192.168.x.x, directly to the attacker.

The vulnerability manifests as a Time-of-Check to Time-of-Use (TOCTOU) logic flaw within the web_fetch tool's network validation pipeline. The application executes content retrieval in two distinct, uncoordinated phases: validation and execution.

During the validation phase, the application calls the validateParams() function. This function resolves the user-provided hostname to an IP address exactly once. The resolved IP address is then evaluated against a denylist of private and restricted IP address ranges. If the IP address is public, the validation phase succeeds.

During the execution phase, the application discards the validated IP address. It passes the original, unresolved hostname to the fetchHTMLContent() function. This function invokes the chromedp headless browser via the chromedp.Navigate() method. The browser performs a secondary, independent DNS resolution to determine the routing destination for the HTTP request.

This separation of resolution events enables a DNS rebinding attack. An attacker controls a malicious DNS server that responds to the initial validation query with a benign public IP address. When the headless browser issues the secondary query fractions of a second later, the malicious DNS server responds with a targeted internal IP address.

The vulnerable code path resides within internal/agent/tools/web_fetch.go. The validation logic correctly identifies private IP ranges but fails to pass the resolved address to the execution context.

The fetchWithChromedp function demonstrates the structural flaw. The targetURL variable retains the original hostname string. When chromedp.Navigate(targetURL) executes, the browser engine relies on the host operating system's DNS resolver to find the destination, creating the TOCTOU condition.

func (t *WebFetchTool) fetchWithChromedp(ctx context.Context, targetURL string) (string, error) {
    // targetURL is not DNS-pinned; browser resolves it independently
    err := chromedp.Run(ctx,
        chromedp.Navigate(targetURL),  // Third DNS lookup occurs here
        chromedp.WaitReady("body", chromedp.ByQuery),
        chromedp.OuterHTML("html", &html),
    )
}

The patch introduced in commit 2b3f76e418e428ac9cab6d63451d25f3052c156d remediates this by implementing strict DNS pinning. The developers created a validateAndResolve() function that captures the validated IP address in a PinnedIP structure.

The fix modifies the chromedp initialization to enforce the use of the PinnedIP. The implementation utilizes the --host-resolver-rules command-line flag, mapping the original hostname directly to the validated IP address. This instructs the browser engine to bypass its internal DNS resolution process entirely.

// Patch Snippet: Enforcing DNS Pinning via Chromedp Flags
hostRule := fmt.Sprintf("MAP %s %s", vp.Host, vp.PinnedIP.String())
opts := append(
    chromedp.DefaultExecAllocatorOptions[:],
    chromedp.Flag("host-resolver-rules", hostRule), // DNS PINNING
    // ...
)

Exploiting CVE-2026-30858 requires the attacker to control an authoritative DNS server for a registered domain. The DNS server must be configured to serve records with a Time-to-Live (TTL) of zero. This configuration prevents intermediate DNS resolvers and the host operating system from caching the initial benign response.

The attacker configures the custom DNS server to alternate its A-record responses. The first incoming request for the domain returns a safe, routable public IP address (e.g., 1.1.1.1). Any subsequent requests within a short timeframe return the target internal IP address (e.g., 127.0.0.1 or 169.254.169.254).

The attack sequence begins when the attacker submits a prompt to the WeKnora agent requesting content from the malicious domain. The agent executes the web_fetch tool. The validation function resolves the domain to the public IP address, passing the security check. The execution function then instructs the headless browser to navigate to the domain.

The browser initiates its own DNS resolution, receiving the secondary response containing the internal IP address. The browser establishes an HTTP connection to the internal service. Once the browser renders the response, the web_fetch tool extracts the DOM content and returns it to the attacker via the agent's output.

# Conceptual DNS Rebinding Server Logic
query_count = {}
 
def handle_dns_request(domain):
    if domain not in query_count:
        query_count[domain] = 1
        return "1.1.1.1", 0  # First request: Return public IP, TTL=0
    else:
        return "127.0.0.1", 0  # Second request: Return private IP, TTL=0

The vulnerability carries a CVSS v3.1 base score of 7.5 (High) under the GHSA advisory, reflecting the unauthenticated, network-based nature of the exploit. While the NVD record indicates a score of 6.5 based on a low privilege requirement, the application's architecture permits zero-privilege exploitation in default network configurations.

Successful exploitation grants an external attacker read access to arbitrary internal HTTP services reachable from the WeKnora application server. This capability exposes unauthenticated internal administrative interfaces, development microservices, and local network management tools. The headless browser execution also permits the execution of JavaScript within the context of the internal service's origin.

In cloud environments, this vulnerability facilitates direct access to the instance metadata service (IMDS) via the 169.254.169.254 endpoint. Attackers utilize this vector to extract temporary IAM credentials, user data scripts, and network configuration details, frequently leading to full cloud environment compromise.

The EPSS score for CVE-2026-30858 is 0.00075, placing it in the 22.39th percentile. While mass automated exploitation is unlikely, the availability of clear proof-of-concept methodologies makes this a viable target for initial access operations against organizations utilizing WeKnora for internal document processing.

The definitive remediation for CVE-2026-30858 is upgrading Tencent WeKnora to version 0.3.0 or later. This release implements comprehensive DNS pinning across the web_fetch tool suite, utilizing the --host-resolver-rules flag for chromedp and manual Host header injection for standard HTTP clients.

Organizations unable to patch immediately must implement compensating network controls. Administrators must configure strict egress firewall rules on the hosts executing the WeKnora application. These rules must explicitly deny outbound traffic destined for RFC 1918 private IP address spaces, loopback addresses, and cloud metadata endpoints (169.254.169.254).

Security teams should adopt defense-in-depth architectural patterns for applications interacting with external web content. Processes handling user-directed HTTP requests, particularly those executing headless browsers, must operate within isolated network namespaces or sandboxed containers. These environments require default-deny network policies that strictly prohibit lateral movement into internal network segments.