| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| mod_css_styles in Roundcube through 1.5.7 and 1.6.x through 1.6.7 insufficiently filters Cascading Style Sheets (CSS) token sequences in rendered e-mail messages, allowing a remote attacker to obtain sensitive information. |
| Incorrect access control in the realtime.cgi endpoint of Deep Sea Electronics devices DSE855 v1.1.0 to v1.1.26 allows attackers to gain access to the admin panel and complete control of the device. |
| An issue in DataPatrol Screenshot watermark, printing watermark agent v.3.5.2.0 allows a physically proximate attacker to obtain sensitive information. NOTE: the Supplier disputes the Print Job Watermark Bypass claim because the watermark is added by hooking into the OS printing mechanism, and thus is not supposed to be visible when previewing a "generated printout" on screen. The Supplier disputes the Screenshot Watermark Bypass claim because the product's documentation explains the step of setting Developer Tools to Disallowed through AD Group Policy. |
| 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. |
| The Xagio SEO plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 7.1.0.5 via the backup functionality due to weak filename structure and lack of protection in the directory. This makes it possible for unauthenticated attackers to extract sensitive data from backups which can include the entire database and site's files. |
| The OpenTelemetry Collector module AWS firehose receiver is for ingesting AWS Kinesis Data Firehose delivery stream messages and parsing the records received based on the configured record type. `awsfirehosereceiver` allows unauthenticated remote requests, even when configured to require a key. OpenTelemetry Collector can be configured to receive CloudWatch metrics via an AWS Firehose Stream. Firehose sets the header `X-Amz-Firehose-Access-Key` with an arbitrary configured string. The OpenTelemetry Collector awsfirehosereceiver can optionally be configured to require this key on incoming requests. However, when this is configured it **still accepts incoming requests with no key**. Only OpenTelemetry Collector users configured with the “alpha” `awsfirehosereceiver` module are affected. This module was added in version v0.49.0 of the “Contrib” distribution (or may be included in custom builds). There is a risk of unauthorized users writing metrics. Carefully crafted metrics could hide other malicious activity. There is no risk of exfiltrating data. It’s likely these endpoints will be exposed to the public internet, as Firehose does not support private HTTP endpoints. A fix was introduced in PR #34847 and released with v0.108.0. All users are advised to upgrade. There are no known workarounds for this vulnerability. |
| Diebold Nixdorf – CWE-200: Exposure of Sensitive Information to an Unauthorized Actor |
| ZKteco – CWE 200 Exposure of Sensitive Information to an Unauthorized Actor |
| 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. |
| An information disclosure vulnerability in Bosscomm IF740 Firmware versions:11001.7078 & v11001.0000 and System versions: 6.25 & 6.00 allows attackers to obtain hardcoded cleartext credentials via the update or boot process. |
| An issue in the AsDB service of HI-SCAN 6040i Hitrax HX-03-19-I allows attackers to enumerate user credentials via crafted GIOP protocol requests. |
| AutoLib Software Systems OPAC v20.10 was discovered to have multiple API keys exposed within the source code. Attackers may use these keys to access the backend API or other sensitive information. |
| An issue in INATRONIC com.inatronic.drivedeck.home 2.6.23 allows a remote attacker to obtain sensitve information via the firmware update process. |
| An issue in EQUES com.eques.plug 1.0.1 allows a remote attacker to obtain sensitive information via the firmware update process. |
| An issue in PCS Engineering Preston Cinema (com.prestoncinema.app) 0.2.0 allows a remote attacker to obtain sensitive information via the firmware update process. |
| An issue in Hubble Connected (com.hubbleconnected.vervelife) 2.00.81 allows a remote attacker to obtain sensitive information via the firmware update process. |
| An issue in LOREX TECHNOLOGY INC com.lorexcorp.lorexping 1.4.22 allows a remote attacker to obtain sensitive information via the firmware update process. |
| An issue in Automatic Systems Maintenance SlimLane 29565_d74ecce0c1081d50546db573a499941b10799fb7 allows a remote attacker to obtain sensitive information via the Racine & FileName parameters in the download-file.php component. |
| The Poll Maker – Versus Polls, Anonymous Polls, Image Polls plugin for WordPress is vulnerable to Basic Information Exposure in all versions up to, and including, 5.8.9 via the 'ays_finish_poll' AJAX action. This makes it possible for unauthenticated attackers to retrieve admin email information which is exposed in the poll response. |
| The gh cli is GitHub’s official command line tool. A security vulnerability has been identified in the GitHub CLI that could leak authentication tokens when cloning repositories containing `git` submodules hosted outside of GitHub.com and ghe.com. This vulnerability stems from several `gh` commands used to clone a repository with submodules from a non-GitHub host including `gh repo clone`, `gh repo fork`, and `gh pr checkout`. These GitHub CLI commands invoke git with instructions to retrieve authentication tokens using the `credential.helper` configuration variable for any host encountered. Prior to version `2.63.0`, hosts other than GitHub.com and ghe.com are treated as GitHub Enterprise Server hosts and have tokens sourced from the following environment variables before falling back to host-specific tokens stored within system-specific secured storage: 1. `GITHUB_ENTERPRISE_TOKEN`, 2. `GH_ENTERPRISE_TOKEN` and 3. `GITHUB_TOKEN` when the `CODESPACES` environment variable is set. The result being `git` sending authentication tokens when cloning submodules. In version `2.63.0`, these GitHub CLI commands will limit the hosts for which `gh` acts as a credential helper to source authentication tokens. Additionally, `GITHUB_TOKEN` will only be used for GitHub.com and ghe.com. Users are advised to upgrade. Additionally users are advised to revoke authentication tokens used with the GitHub CLI and to review their personal security log and any relevant audit logs for actions associated with their account or enterprise |
