Discourse is an open source discussion platform. In versions prior to 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0, moderators can access the `top_uploads` admin report which should be restricted to admins only. This report displays direct URLs to all uploaded files on the site, including sensitive content such as user data exports, admin backups, and other private attachments that moderators should not have access to. This issue is patched in versions 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0. There is no workaround. Limit moderator privileges to trusted users until the patch is applied.

A security vulnerability in the /apis/dashboard.grafana.app/* endpoints allows authenticated users to bypass dashboard and folder permissions. The vulnerability affects all API versions (v0alpha1, v1alpha1, v2alpha1). Impact: - Viewers can view all dashboards/folders regardless of permissions - Editors can view/edit/delete all dashboards/folders regardless of permissions - Editors can create dashboards in any folder regardless of permissions - Anonymous users with viewer/editor roles are similarly affected Organization isolation boundaries remain intact. The vulnerability only affects dashboard access and does not grant access to datasources.

Discourse is an open source discussion platform. In versions prior to 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0, an endpoint lets any authenticated user bypass the ai_discover_persona access controls and gain ongoing DM access to personas that may be wired to staff-only categories, RAG document sets, or automated tooling, enabling unauthorized data disclosure. Because the controller also accepts arbitrary user_id, an attacker can impersonate other accounts to trigger unwanted AI conversations on their behalf, generating confusing or abusive PM traffic. This issue is patched in versions 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0. No known workarounds are available.

Discourse is an open source discussion platform. Versions prior to 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0 have an application level denial of service vulnerabilityin the username change functionality at try.discourse.org. The vulnerability allows attackers to cause noticeable server delays and resource exhaustion by sending large JSON payloads to the username preference endpoint PUT /u//preferences/username, resulting in degraded performance for other users and endpoints. This issue is patched in versions 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0. No known workarounds are available.

In GnuPG before 2.5.17, a stack-based buffer overflow exists in tpm2daemon during handling of the PKDECRYPT command for TPM-backed RSA and ECC keys.

Knockpy 4.1.1 contains a CSV injection vulnerability that allows attackers to inject malicious formulas into CSV reports through unfiltered server headers. Attackers can manipulate server response headers to include spreadsheet formulas that will execute when the CSV is opened in spreadsheet applications.

Out-of-bounds Write, Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') vulnerability in tildearrow furnace (extern/zlib modules). This vulnerability is associated with program files inflate.C.

Kargo manages and automates the promotion of software artifacts. Prior to versions 1.8.7, 1.7.7, and 1.6.3, a bug was found with authentication checks on the `GetConfig()` API endpoint. This allowed unauthenticated users to access this endpoint by specifying an `Authorization` header with any non-empty `Bearer` token value, regardless of validity. This vulnerability did allow for exfiltration of configuration data such as endpoints for connected Argo CD clusters. This data could allow an attacker to enumerate cluster URLs and namespaces for use in subsequent attacks. Additionally, the same bug affected the `RefreshResource` endpoint. This endpoint does not lead to any information disclosure, but could be used by an unauthenticated attacker to perform a denial-of-service style attack against the Kargo API. `RefreshResource` sets an annotation on specific Kubernetes resources to trigger reconciliations. If run on a constant loop, this could also slow down legitimate requests to the Kubernetes API server. This problem has been patched in Kargo versiosn 1.8.7, 1.7.7, and 1.6.3. There are no workarounds for this issue.

Kyverno is a policy engine designed for cloud native platform engineering teams. Versions prior to 1.16.3 and 1.15.3 have a critical authorization boundary bypass in namespaced Kyverno Policy apiCall. The resolved `urlPath` is executed using the Kyverno admission controller ServiceAccount, with no enforcement that the request is limited to the policy’s namespace. As a result, any authenticated user with permission to create a namespaced Policy can cause Kyverno to perform Kubernetes API requests using Kyverno’s admission controller identity, targeting any API path allowed by that ServiceAccount’s RBAC. This breaks namespace isolation by enabling cross-namespace reads (for example, ConfigMaps and, where permitted, Secrets) and allows cluster-scoped or cross-namespace writes (for example, creating ClusterPolicies) by controlling the urlPath through context variable substitution. Versions 1.16.3 and 1.15.3 contain a patch for the vulnerability.

vLLM is an inference and serving engine for large language models (LLMs). Prior to version 0.14.1, a Server-Side Request Forgery (SSRF) vulnerability exists in the `MediaConnector` class within the vLLM project's multimodal feature set. The load_from_url and load_from_url_async methods obtain and process media from URLs provided by users, using different Python parsing libraries when restricting the target host. These two parsing libraries have different interpretations of backslashes, which allows the host name restriction to be bypassed. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources. This vulnerability is particularly critical in containerized environments like `llm-d`, where a compromised vLLM pod could be used to scan the internal network, interact with other pods, and potentially cause denial of service or access sensitive data. For example, an attacker could make the vLLM pod send malicious requests to an internal `llm-d` management endpoint, leading to system instability by falsely reporting metrics like the KV cache state. Version 0.14.1 contains a patch for the issue.