CVE-2026-118376 in WeKnora
Summary
by MITRE • 10/28/2026
WeKnora before 0.8.2 contains a server-side request forgery vulnerability in isRestrictedIP() that misclassifies NAT64-prefixed IPv6 addresses as public. Authenticated attackers can supply URLs resolving to NAT64 encodings of internal addresses via web_fetch or URL-based knowledge import to reach internal services or cloud metadata endpoints.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in WeKnora versions prior to 0.8.2 represents a critical server-side request forgery flaw rooted in the misclassification of network address types during IP validation processes. Specifically, the isRestrictedIP function fails to correctly identify NAT64-prefixed IPv6 addresses as private or internal ranges. This technical oversight allows authenticated attackers to bypass security controls that are designed to restrict access to local resources by exploiting the unique characteristics of NAT64 translation mechanisms. By supplying URLs that resolve to NAT64 encodings of internal IP addresses, an attacker can effectively mask their requests as originating from external public networks, thereby circumventing restrictions intended for private address spaces.
From a technical perspective, this flaw leverages the way IPv6-to-IPv4 transition technologies handle address translation. NAT64 is designed to allow IPv6-only clients to communicate with IPv4 servers by translating addresses and headers. However, when an application like WeKnora checks if an IP is restricted or internal, it may not account for the fact that a public-looking IPv6 address can map directly to a private IPv4 address on the backend network. This misclassification creates a blind spot in the access control logic, enabling the exploitation of web_fetch functions and URL-based knowledge import features. These functionalities typically allow users to fetch content from external sources or integrate data via URLs, but without proper validation against NAT64 mappings, they become vectors for internal network reconnaissance and unauthorized access.
The operational impact of this vulnerability is significant, particularly in environments where WeKnora is deployed within a corporate intranet or connected to cloud infrastructure. An authenticated attacker can utilize the application as a pivot point to reach sensitive internal services that are not exposed to the public internet but are accessible via local network routes. Furthermore, the ability to target cloud metadata endpoints poses an severe risk of credential theft and further lateral movement. Cloud providers such as AWS, Azure, and GCP expose instance metadata through specific IP addresses or hostnames that contain highly privileged authentication tokens and configuration details. Accessing these endpoints can lead to full compromise of the underlying virtual machine instances, granting attackers control over cloud resources and potentially leading to data exfiltration or ransomware deployment across the organization's infrastructure.
This vulnerability aligns with CWE-918, which describes Server-Side Request Forgery (SSRF), specifically involving misinterpretation of input data regarding network topology. Additionally, it maps to MITRE ATT&CK techniques such as T1504.003 for Web Service Discovery and potentially T1078.004 for Cloud Accounts if metadata endpoints are successfully accessed. The exploitation path relies on the attacker's ability to authenticate into the WeKnora application first, which limits the attack surface to insider threats or compromised user credentials rather than unauthenticated remote attacks.
To mitigate this risk, organizations running WeKnora versions earlier than 0.8.2 should immediately upgrade to version 0.8.2 or later where the isRestrictedIP function has been corrected to properly handle NAT64 prefixes and other IPv6 transition mechanisms. In addition to upgrading, administrators should implement network-level controls such as egress filtering on the server hosting WeKnora to prevent outbound connections to private IP ranges and cloud metadata endpoints regardless of application-layer validation. Deploying a Web Application Firewall with SSRF detection capabilities can also provide an additional layer of defense by inspecting outgoing requests for patterns indicative of internal resource access. Regular audits of URL-based input handling functions are recommended to ensure that all external-facing features adhere to strict allow-lists and do not inadvertently facilitate internal network traversal.