CVE Alert: CVE-2025-11046 – Tencent – WeKnora

CVE-2025-11046

HIGHNo exploitation known

A security flaw has been discovered in Tencent WeKnora 0.1.0. This impacts the function testEmbeddingModel of the file /api/v1/initialization/embedding/test. The manipulation of the argument baseUrl results in server-side request forgery. The attack can be launched remotely. The exploit has been released to the public and may be exploited. It is advisable to upgrade the affected component. The vendor responds: "We have confirmed that the issue mentioned in the report does not exist in the latest releases".

CVSS v3.1 (7.3)
Vendor
Tencent
Product
WeKnora
Versions
0.1.0
CWE
CWE-918, Server-Side Request Forgery
Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L/E:P/RL:O/RC:C
Published
2025-09-26T21:02:05.829Z
Updated
2025-09-26T21:02:05.829Z

AI Summary Analysis

Risk verdict

High risk: remote, unauthenticated SSRF with a publicly available exploit; urgent attention recommended.

Why this matters

The flaw allows an attacker to manipulate a server-side parameter and induce the application to make arbitrary network requests. With PoC availability and public exploitation, an attacker could probe internal resources, cloud endpoints, or other services reachable from the server, potentially exposing sensitive data or creating misuse of downstream systems.

Most likely attack path

An attacker sends crafted input to the vulnerable endpoint (/api/v1/initialization/embedding/test) to alter baseUrl, triggering SSRF. No user interaction or credentials are required, and the attacker can operate over the network. The impact is limited to low integrity/availability in the CVSS terms, but combined with reachable internal targets, it enables discovery or partial access to internal resources.

Who is most exposed

Public-facing API deployments and microservices architectures where the endpoint is exposed and input is not strictly sanitised are most at risk. Environments with permissive egress and internal service connectivity are particularly susceptible to lateral movement via SSRF.

Detection ideas

  • Outbound requests from the web service to non‑allowed internal or cloud endpoints triggered by the vulnerable call.
  • Logs showing unusual baseUrl values or SSRF-like patterns in testEmbeddingModel requests.
  • Sudden spikes in outbound traffic to internal networks or non-routable hosts after API calls.
  • Anomalous patterns in access logs for /api/v1/initialization/embedding/test.
  • Indicators of failed SSRF attempts or repetitive probing from the same source.

Mitigation and prioritisation

  • Upgrade or apply vendor-recommended patch; verify whether latest releases mitigate the issue.
  • Implement strict input validation and allowlists for the baseUrl argument; disable or harden the vulnerable function if possible.
  • Enforce network egress controls to restrict server outbound calls to approved destinations only.
  • Deploy WAF/risk rules to detect and block SSRF payloads targeting internal endpoints.
  • Operationalise targeted monitoring and alerting; coordinate patch testing in staging before production rollout. If KEV or EPSS signals are confirmed, elevate to priority 1.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on “Patreon” or “Buy Me A Coffee” using the buttons below

To keep up to date follow us on the below channels.