Unvalidated HTTP redirects enable SSRF in Tencent WeKnora

WeKnora before 0.7.0 fails to re-validate HTTP redirect targets in the POST /api/v1/knowledge-bases/:id/knowledge/url endpoint when downloading documents from user-supplied URLs. Authenticated attackers can bypass initial SSRF validation by supplying a public URL that redirects to internal network addresses, allowing access to internal services and cloud metadata.

• Tencent WeKnora is affected from version 0.5.2 through versions less than 0.7.0, according to the CNA's semver constraint.
• The CPE applicability data describes the same boundary, starting at 0.5.2 and ending before 0.7.0.
• The supplied record does not identify additional products or parallel release branches.

This is a Server-Side Request Forgery (SSRF) flaw in WeKnora's URL-based document import flow. The POST /api/v1/knowledge-bases/:id/knowledge/url endpoint accepts a user-supplied URL and downloads a document from it. The initial SSRF validation is not applied again to the destination reached after an HTTP redirect, so an authenticated attacker can use a public URL to make the server request an internal address. In the affected code path, downloadFileFromURL uses a standard HTTP client and states that SSRF validation is the caller's responsibility, leaving redirect handling outside the validation boundary shown in that implementation. The patch moves file_url downloads to an SSRF-safe HTTP client and adds redirect-aware guards to the Playwright-based docreader path. The available evidence does not fully identify which internal services can be reached in every deployment environment.

The flaw is reachable over the network through the URL import endpoint and requires an authenticated account. The structured data indicates that no additional user interaction is required and that the attack path has low complexity. The attacker must control the URL submitted to the document import function and cause that URL to redirect to an internal destination. The record marks a public exploit as available, but it does not provide confirmation of exploitation in production environments. The supplied data does not confirm a known_exploited status.

The flaw allows an authenticated account to turn WeKnora's document download feature into a server-side HTTP request origin for destinations that an external user should not reach directly. The confirmed technical outcome is potential disclosure of information from internal services and cloud metadata, with the primary effect on confidentiality. The available evidence does not show that the flaw directly permits data modification, privilege escalation within WeKnora, or service disruption. Actual exposure depends on the networks, internal services, and metadata access available to the WeKnora server in the deployment environment.

• Information disclosure: The WeKnora server may be used to read responses from services that are accessible only from the internal network.
• Cloud exposure: If the environment permits access to metadata services, sensitive data returned by those services could be disclosed.
• Organisational scope: The confirmed risk primarily concerns confidentiality of services and data reachable from the WeKnora host; the available evidence does not establish data modification or service disruption.
• Precondition: The attack path requires an authenticated WeKnora account with access to the URL-based document import function.

1. Upgrade Tencent WeKnora to 0.7.0, the release boundary identified by the CNA as outside the affected range. Do not assume that every higher or parallel release branch is safe without verifying it separately.
2. If an upgrade cannot be completed immediately, restrict access to POST /api/v1/knowledge-bases/:id/knowledge/url to trusted accounts and networks, and apply egress controls so the WeKnora server cannot freely connect to internal networks or metadata services. This is defense in depth, not a confirmed replacement for the vendor fix.
3. After upgrading, verify that URL downloads use an SSRF-safe HTTP client and that every redirect destination is checked, including the Playwright-based docreader path.
4. Review requests and outbound connections generated before the upgrade to determine whether further investigation is warranted. The supplied evidence does not specify a recovery workflow or credential-rotation requirement.

• Inventory running WeKnora deployments and identify the version of github.com/Tencent/WeKnora; prioritize instances in the affected range.
• Review access logs, audit logs, and application logs for authenticated requests to POST /api/v1/knowledge-bases/:id/knowledge/url, especially requests whose supplied URL points to a redirecting server.
• Review proxy, firewall, DNS, or egress telemetry from WeKnora hosts for connections made during document imports to private networks, link-local addresses, or metadata services. This is precautionary monitoring, not a confirmed IOC for this flaw.
• Verify that the deployed implementation evaluates redirect destinations with the SSRF policy instead of validating only the original URL.
• Review cloud platform access logs for requests originating from WeKnora hosts. The absence of matching log evidence does not prove that the deployment is safe.