| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Decidim is a participatory democracy framework, written in Ruby on Rails, originally developed for the Barcelona City government online and offline participation website. If an attacker can infer the slug or URL of an unpublished or private resource, and this resource can be embbeded (such as a Participatory Process, an Assembly, a Proposal, a Result, etc), then some data of this resource could be accessed. This vulnerability is fixed in 0.27.6. |
| The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The `BareMetalHost` (BMH) CRD allows the `userData`, `metaData`, and `networkData` for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the `Name` and `Namespace` of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a `Secret` from any namespace. A user with access to create or edit a `BareMetalHost` can thus exfiltrate a `Secret` from another namespace by using it as e.g. the `userData` for provisioning some host (note that this need not be a real host, it could be a VM somewhere).
BMO will only read a key with the name `value` (or `userData`, `metaData`, or `networkData`), so that limits the exposure somewhat. `value` is probably a pretty common key though. Secrets used by _other_ `BareMetalHost`s in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a `BareMetalHost`. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.
The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces. |
| Element is a Matrix web client built using the Matrix React SDK. Element Web versions 1.11.70 through 1.11.80 contain a vulnerability which can, under specially crafted conditions, lead to the access token becoming exposed to third parties. At least one vector has been identified internally, involving malicious widgets, but other vectors may exist. Note that despite superficial similarity to CVE-2024-47771, this is an entirely separate vulnerability, caused by a separate piece of code included only in Element Web. Element Web and Element Desktop share most but not all, of their code and this vulnerability exists in the part of the code base which is not shared between the projects. Users are strongly advised to upgrade to version 1.11.81 to remediate the issue. As a workaround, avoid granting permissions to untrusted widgets. |
| Exposure of sensitive information to an unauthorized actor for some Edge Orchestrator software for Intel(R) Tiber™ Edge Platform may allow an authenticated user to potentially enable information disclosure via local access. |
| matrix-js-sdk is the Matrix Client-Server SDK for JavaScript and TypeScript. In matrix-js-sdk versions versions 9.11.0 through 34.7.0, the method `MatrixClient.sendSharedHistoryKeys` is vulnerable to interception by malicious homeservers. The method was introduced by MSC3061) and is commonly used to share historical message keys with newly invited users, granting them access to past messages in the room. However, it unconditionally sends these "shared" keys to all of the invited user's devices, regardless of whether the user's cryptographic identity is verified or whether the user's devices are signed by that identity. This allows the attacker to potentially inject its own devices to receive sensitive historical keys without proper security checks. Note that this only affects clients running the SDK with the legacy crypto stack. Clients using the new Rust cryptography stack (i.e. those that call `MatrixClient.initRustCrypto()` instead of `MatrixClient.initCrypto()`) are unaffected by this vulnerability, because `MatrixClient.sendSharedHistoryKeys()` raises an exception in such environments. The vulnerability was fixed in matrix-js-sdk 34.8.0 by removing the vulnerable functionality. As a workaround, remove use of affected functionality from clients. |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Webcraftic Hide login page allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Hide login page: from n/a through 1.1.9. |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Payara Platform Payara Server (Logging modules) allows Sensitive credentials posted in plain-text on the server log.This issue affects Payara Server: from 6.0.0 before 6.18.0, from 6.2022.1 before 6.2024.9, from 5.20.0 before 5.67.0, from 5.2020.2 before 5.2022.5, from 4.1.2.191.0 before 4.1.2.191.50. |
| The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. Baremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource `BMCEventSubscription`. Prior to versions 0.8.1 and 0.9.1, an adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a `BMCEventSubscription` in his authorized namespace and then load Secrets from his unauthorized namespaces to his authorized namespace via the Baremetal Operator, causing Secret Leakage. The patch makes BMO refuse to read Secrets from other namespace than where the corresponding BMH resource is. The patch does not change the `BMCEventSubscription` API in BMO, but stricter validation will fail the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES CR has already been deployed. The issue exists for all versions of BMO, and is patched in BMO releases v0.9.1 and v0.8.1. Prior upgrading to patched BMO version, duplicate any existing Secret pointed to by `BMCEventSubscription`'s `httpHeadersRef` to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets. As a workaround, the operator can configure BMO RBAC to be namespace scoped, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces, and/or use `WATCH_NAMESPACE` configuration option to limit BMO to single namespace. |
| A flaw was found in Keycloak in OAuth 2.0 Pushed Authorization Requests (PAR). Client-provided parameters were found to be included in plain text in the KC_RESTART cookie returned by the authorization server's HTTP response to a `request_uri` authorization request, possibly leading to an information disclosure vulnerability. |
| Information disclosure in the Widget: Cocoa component. This vulnerability was fixed in Firefox 149, Firefox ESR 140.9, Thunderbird 149, and Thunderbird 140.9. |
| Exposure of sensitive information to an unauthorized actor in Azure Data Factory allows an unauthorized attacker to disclose information over a network. |
| Exposure of sensitive information to an unauthorized actor in Windows Accessibility Infrastructure (ATBroker.exe) allows an authorized attacker to disclose information locally. |
| Storybook is a frontend workshop for building user interface components and pages in isolation. A vulnerability present starting in versions 7.0.0 and prior to versions 7.6.21, 8.6.15, 9.1.17, and 10.1.10 relates to Storybook’s handling of environment variables defined in a `.env` file, which could, in specific circumstances, lead to those variables being unexpectedly bundled into the artifacts created by the `storybook build` command. When a built Storybook is published to the web, the bundle’s source is viewable, thus potentially exposing those variables to anyone with access. For a project to potentially be vulnerable to this issue, it must build the Storybook (i.e. run `storybook build` directly or indirectly) in a directory that contains a `.env` file (including variants like `.env.local`) and publish the built Storybook to the web. Storybooks built without a `.env` file at build time are not affected, including common CI-based builds where secrets are provided via platform environment variables rather than `.env` files. Storybook runtime environments (i.e. `storybook dev`) are not affected. Deployed applications that share a repo with your Storybook are not affected. Users should upgrade their Storybook—on both their local machines and CI environment—to version .6.21, 8.6.15, 9.1.17, or 10.1.10 as soon as possible. Maintainers additionally recommend that users audit for any sensitive secrets provided via `.env` files and rotate those keys. Some projects may have been relying on the undocumented behavior at the heart of this issue and will need to change how they reference environment variables after this update. If a project can no longer read necessary environmental variable values, either prefix the variables with `STORYBOOK_` or use the `env` property in Storybook’s configuration to manually specify values. In either case, do not include sensitive secrets as they will be included in the built bundle. |
| Discourse is an open-source discussion platform. From versions 2026.1.0-latest to before 2026.1.3, 2026.2.0-latest to before 2026.2.2, and 2026.3.0-latest to before 2026.3.0, the discourse-subscriptions plugin leaks stripe API keys across sites in a multisite cluster resulting in the potential for stripe related information to be leaked across sites within the same multisite cluster. This issue has been patched in versions 2026.1.3, 2026.2.2, and 2026.3.0. |
| Discourse is an open-source discussion platform. From versions 2026.1.0-latest to before 2026.1.3, 2026.2.0-latest to before 2026.2.2, and 2026.3.0-latest to before 2026.3.0, moderators could export CSV data for admin-restricted reports, bypassing the report visibility restrictions. This could expose sensitive operational data intended only for admins. This issue has been patched in versions 2026.1.3, 2026.2.2, and 2026.3.0. |
| Discourse is an open-source discussion platform. From versions 2026.1.0-latest to before 2026.1.3, 2026.2.0-latest to before 2026.2.2, and 2026.3.0-latest to before 2026.3.0, there is possible channel membership inference from chat user search without authorization. This issue has been patched in versions 2026.1.3, 2026.2.2, and 2026.3.0. |
| Discourse is an open-source discussion platform. From versions 2026.1.0-latest to before 2026.1.3, 2026.2.0-latest to before 2026.2.2, and 2026.3.0-latest to before 2026.3.0, non-staff users could access read receipt information for staff-only posts they weren't supposed to see. No post content was exposed, only metadata about who read the post and when. This issue has been patched in versions 2026.1.3, 2026.2.2, and 2026.3.0. |
| Discourse is an open-source discussion platform. From versions 2026.1.0-latest to before 2026.1.3, 2026.2.0-latest to before 2026.2.2, and 2026.3.0-latest to before 2026.3.0, an authenticated user can obtain shared draft topic titles by sending an inline onebox request with a category_id parameter matching the shared drafts category. This issue has been patched in versions 2026.1.3, 2026.2.2, and 2026.3.0. |
| Discourse is an open-source discussion platform. From versions 2026.1.0-latest to before 2026.1.3, 2026.2.0-latest to before 2026.2.2, and 2026.3.0-latest to before 2026.3.0, an authorization bypass in the Category Chatables Controller show action allowed moderators to get information on hidden groups names and user count. This issue has been patched in versions 2026.1.3, 2026.2.2, and 2026.3.0. |
| The application allows PDF JavaScript and document/print actions (such as WillPrint/DidPrint) to update form fields, annotations, or optional content groups (OCGs) immediately before or after redaction, encryption, or printing. These script‑driven updates are not fully covered by the existing redaction, encryption, and printing logic, which, under specific document structures and user workflows, may cause a small amount of sensitive content to remain unremoved or unencrypted as expected, or result in printed output that slightly differs from what was reviewed on screen. |
