CVE-2026-30858: Tencent Weknora SSRF Vulnerability

CVE-2026-30858 Overview

CVE-2026-30858 is a DNS rebinding vulnerability affecting Tencent WeKnora, an LLM-powered framework designed for deep document understanding and semantic retrieval. The vulnerability exists in the web_fetch tool component and allows unauthenticated attackers to bypass URL validation mechanisms, potentially gaining access to internal network resources and sensitive services.

Critical Impact
Unauthenticated attackers can exploit DNS rebinding to access internal resources including private IP addresses (127.0.0.1, 192.168.x.x), potentially leading to data exfiltration from sensitive local services.

Affected Products

Tencent WeKnora versions prior to 0.3.0

Discovery Timeline

2026-03-07 - CVE CVE-2026-30858 published to NVD
2026-03-09 - Last updated in NVD database

Technical Details for CVE-2026-30858

Vulnerability Analysis

This vulnerability is classified under CWE-918 (Server-Side Request Forgery), though it specifically leverages DNS rebinding as the attack mechanism. DNS rebinding exploits the time-of-check to time-of-use (TOCTOU) gap that occurs when URL validation and actual HTTP requests happen at different points in time.

In the context of WeKnora's web_fetch tool, the vulnerability allows attackers to craft malicious domains that behave differently during the validation phase versus the execution phase. During initial URL validation, the malicious domain resolves to a legitimate public IP address, passing security checks. However, when the actual fetch request is made, the DNS record has been changed to resolve to a private IP address such as 127.0.0.1 or addresses in the 192.168.x.x range.

This SSRF variant is particularly dangerous in LLM-powered frameworks like WeKnora because these tools are designed to fetch and process external content as part of their document understanding capabilities. An attacker can potentially access internal APIs, metadata services, configuration endpoints, or other sensitive resources that should not be exposed externally.

Root Cause

The root cause stems from insufficient DNS rebinding protections in the web_fetch tool's URL validation logic. The validation mechanism performs DNS resolution during the check phase but does not enforce that the resolved IP address remains consistent when the actual HTTP request is made. This allows attackers to exploit the inherent race condition between DNS validation and request execution.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker sets up a malicious DNS server configured to respond with a public IP address for initial queries (passing validation) and then quickly switches to responding with a private/internal IP address for subsequent queries. When WeKnora's web_fetch tool processes a URL pointing to this malicious domain, it validates the initial public IP but ultimately connects to the internal resource, bypassing network segmentation and access controls.

The attacker-controlled domain might initially resolve to something like 203.0.113.50 (a public IP) during validation, then resolve to 127.0.0.1 or 169.254.169.254 (cloud metadata service) when the actual request is made, enabling access to localhost services or cloud instance metadata that could contain sensitive credentials.

Detection Methods for CVE-2026-30858

Indicators of Compromise

Unusual DNS queries to domains with extremely low TTL values (often 0 or near-0 seconds)
HTTP requests from WeKnora instances targeting internal IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Outbound connections to cloud metadata endpoints (169.254.169.254) from WeKnora processes
DNS resolution patterns showing the same domain resolving to different IP addresses within short time windows

Detection Strategies

Implement network monitoring to detect requests to internal IP ranges originating from WeKnora application servers
Configure DNS logging to identify domains with suspiciously low TTL values being queried by WeKnora services
Deploy web application firewalls (WAF) with rules to block SSRF patterns targeting private IP ranges
Monitor for unusual access patterns to internal services that should not receive traffic from LLM framework components

Monitoring Recommendations

Enable detailed logging for the web_fetch tool to capture all URL requests and their resolved IP addresses
Set up alerts for any network traffic from WeKnora instances to RFC 1918 private address spaces
Implement egress filtering with logging to detect potential data exfiltration attempts
Review WeKnora access logs for patterns consistent with SSRF probing or reconnaissance

How to Mitigate CVE-2026-30858

Immediate Actions Required

Upgrade Tencent WeKnora to version 0.3.0 or later immediately
Audit existing WeKnora deployments to determine if unauthorized access to internal resources has occurred
Implement network-level controls to restrict WeKnora's ability to connect to internal IP ranges
Review access logs for any suspicious activity that may indicate prior exploitation

Patch Information

Tencent has addressed this vulnerability in WeKnora version 0.3.0. The patch implements proper DNS rebinding protections to ensure that URL validation and request execution use consistent IP address resolution. Organizations should upgrade to the patched version as soon as possible.

For detailed patch information, refer to the GitHub Security Advisory GHSA-h6gw-8f77-mmmp.

Workarounds

Deploy network segmentation to prevent WeKnora instances from accessing internal network resources
Configure firewall rules to block outbound connections from WeKnora to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8)
Implement a proxy server for all WeKnora outbound requests with strict URL allowlisting
If using cloud infrastructure, block access to metadata endpoints (169.254.169.254) from WeKnora containers or instances

bash

# Example iptables rules to block access to private IP ranges from WeKnora
# Apply to the host running WeKnora services
iptables -A OUTPUT -m owner --uid-owner weknora -d 127.0.0.0/8 -j DROP
iptables -A OUTPUT -m owner --uid-owner weknora -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -m owner --uid-owner weknora -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -m owner --uid-owner weknora -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -m owner --uid-owner weknora -d 169.254.169.254 -j DROP