| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability has been identified in SINUMERIK 828D V4 (All versions < V4.95 SP3), SINUMERIK 840D sl V4 (All versions < V4.95 SP3 in connection with using Create MyConfig (CMC) <= V4.8 SP1 HF6), SINUMERIK ONE (All versions < V6.23 in connection with using Create MyConfig (CMC) <= V6.6), SINUMERIK ONE (All versions < V6.15 SP4 in connection with using Create MyConfig (CMC) <= V6.6). Affected systems, that have been provisioned with Create MyConfig (CMC), contain a Insertion of Sensitive Information into Log File vulnerability. This could allow a local authenticated user with low privileges to read sensitive information and thus circumvent access restrictions. |
| Insertion of Sensitive Information into Log File vulnerability observed in FLEXON. Some information may be improperly disclosed through https access.
This issue affects FLXEON through <= 9.3.4. |
| Insertion of Sensitive Information into Log File vulnerability in StylemixThemes Masterstudy LMS Starter.This issue affects Masterstudy LMS Starter: from n/a through 1.1.8. |
| The Quickcreator – AI Blog Writer plugin for WordPress is vulnerable to Sensitive Information Exposure in versions 0.0.9 to 0.1.17 through the /wp-content/plugins/quickcreator/dupasrala.txt file. This makes it possible for unauthenticated attackers to view the plugin's API key and subsequently use that to perform actions on the site like creating new posts and injecting XSS payloads. |
| A vulnerability has been identified in Rancher Manager, where sensitive
information, including secret data, cluster import URLs, and
registration tokens, is exposed to any entity with access to Rancher
audit logs. |
| The AuthKit library for Remix provides convenient helpers for authentication and session management using WorkOS & AuthKit with Remix. In affected versions refresh tokens are logged to the console when the disabled by default `debug` flag, is enabled. This issue has been patched in version 0.4.1. All users are advised to upgrade. There are no known workarounds for this vulnerability. |
| On Windows systems, the Arc configuration files resulted to be world-readable.
This can lead to information disclosure by local attackers, via exfiltration of sensitive data from configuration files. |
| The WP Database Backup – Unlimited Database & Files Backup by Backup for WP plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 7.3 via publicly accessible back-up files. This makes it possible for unauthenticated attackers to extract sensitive data including all information stored in the database. |
| @backstage/plugin-scaffolder-backend is the backend for the default Backstage software templates. Prior to version 2.1.1, duplicate logging of the input values in the fetch:template action in the Scaffolder meant that some of the secrets were not properly redacted. If ${{ secrets.x }} is not passed through to fetch:template there is no impact. This issue has been resolved in 2.1.1 of the scaffolder-backend plugin. A workaround for this issue involves Template Authors removing the use of ${{ secrets }} being used as an argument to fetch:template. |
| Sentry is a developer-first error tracking and performance monitoring platform. Sentry's Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the deprecated Slack verification token. With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration. The request body is leaked in log entries matching `event == "slack.*" && name == "sentry.integrations.slack" && request_data == *`. The deprecated slack verification token, will be found in the `request_data.token` key. **SaaS users** do not need to take any action. **Self-hosted users** should upgrade to version 24.5.0 or higher, rotate their Slack verification token, and use the Slack Signing Secret instead of the verification token. For users only using the `slack.signing-secret` in their self-hosted configuration, the legacy verification token is not used to verify the webhook payload. It is ignored. Users unable to upgrade should either set the `slack.signing-secret` instead of `slack.verification-token`. The signing secret is Slack's recommended way of authenticating webhooks. By having `slack.singing-secret` set, Sentry self-hosted will no longer use the verification token for authentication of the webhooks, regardless of whether `slack.verification-token` is set or not. Alternatively if the self-hosted instance is unable to be upgraded or re-configured to use the `slack.signing-secret`, the logging configuration can be adjusted to not generate logs from the integration. The default logging configuration can be found in `src/sentry/conf/server.py`. **Services should be restarted once the configuration change is saved.**
|
| Insertion of Sensitive Information into Log File vulnerability in Lukman Nakib Debug Log – Manger Tool.This issue affects Debug Log – Manger Tool: from n/a through 1.4.5. |
| Information exposure in the logging system in Yugabyte Platform allows local attackers with access to application logs to obtain database user credentials in log files, potentially leading to unauthorized database access. |
| Valtimo is an open source business process and case management platform. When opening a form in Valtimo, the access token (JWT) of the user is exposed to `api.form.io` via the the `x-jwt-token` header. An attacker can retrieve personal information from this token, or use it to execute requests to the Valtimo REST API on behalf of the logged-in user. This issue is caused by a misconfiguration of the Form.io component.
The following conditions have to be met in order to perform this attack: An attacker needs to have access to the network traffic on the `api.form.io` domain; the content of the `x-jwt-token` header is logged or otherwise available to the attacker; an attacker needs to have network access to the Valtimo API; and an attacker needs to act within the time-to-live of the access token. The default TTL in Keycloak is 5 minutes.
Versions 10.8.4, 11.1.6 and 11.2.2 have been patched. |
| Himmelblau is an interoperability suite for Microsoft Azure Entra ID and Intune. Starting in version 0.7.0 and prior to versions 0.7.15 and 0.8.3, Himmelblau is vulnerable to leaking credentials in debug logs. When debug logging is enabled, user access tokens are inadvertently logged, potentially exposing sensitive authentication data. Similarly, Kerberos Ticket-Granting Tickets (TGTs) are logged when debug logging is enabled. Both issues pose a risk of exposing sensitive credentials, particularly in environments where debug logging is enabled. Himmelblau versions 0.7.15 and 0.8.3 contain a patch that fixes both issues. Some workarounds are available for users who are unable to upgrade. For the **logon compliance script issue**, disable the `logon_script` option in `/etc/himmelblau/himmelblau.conf`, and avoid using the `-d` flag when starting the `himmelblaud` daemon. For the Kerberos CCache issue, one may disable debug logging globally by setting the `debug` option in `/etc/himmelblau/himmelblau.conf` to `false` and avoiding the `-d` parameter when starting `himmelblaud`. |
| A security issue in Sitevision version 10.3.1 and older allows a remote attacker, in certain (non-default) scenarios, to gain access to the private keys used for signing SAML Authn requests. The underlying issue is a Java keystore that may become accessible and downloadable via WebDAV. This keystore is protected with a low-complexity, auto-generated password. |
| zot is ancontainer image/artifact registry based on the Open Container Initiative Distribution Specification. Prior to version 2.1.3 (corresponding to pseudoversion 1.4.4-0.20250522160828-8a99a3ed231f), when using Keycloak as an oidc provider, the clientsecret gets printed into the container stdout logs for an example at container startup. Version 2.1.3 (corresponding to pseudoversion 1.4.4-0.20250522160828-8a99a3ed231f) fixes the issue. |
| Okta On-Premises Provisioning (OPP) agents log certain user data during administrator-initiated password resets. This vulnerability allows an attacker with access to the local servers running OPP agents to retrieve user personal information and temporary passwords created during password reset. You are affected by this vulnerability if the following preconditions are met: Local server running OPP agent with versions >=2.2.1 and <= 2.3.0, and User account has had an administrator-initiated password reset while using the affected versions. |
| Information disclosure and exposure of authentication FTP credentials over the debug port 1604 in the MINOVA TTA service. This allows unauthenticated remote access to an active FTP account containing sensitive internal data and import structures. In environments where this FTP server is part of automated business processes (e.g. EDI or data integration), this could lead to data manipulation, extraction, or abuse. Debug ports 1602, 1603 and 1636 also expose service architecture information and system activity logs |
| An information disclosure vulnerability exists in Yugabyte Anywhere, where the LDAP bind password is logged in plaintext within application logs. This flaw results in the unintentional exposure of sensitive information in Yugabyte Anywhere logs, potentially allowing unauthorized users with access to these logs to view the LDAP bind password. An attacker with log access could exploit this vulnerability to gain unauthorized access to the LDAP server, leading to potential exposure or compromise of LDAP-managed resources
This issue affects YugabyteDB Anywhere: from 2.20.0.0 before 2.20.7.0, from 2.23.0.0 before 2.23.1.0, from 2024.1.0.0 before 2024.1.3.0. |
| Improper restriction of environment variables in Elastic Defend can lead to exposure of sensitive information such as API keys and tokens via automatic transmission of unfiltered environment variables to the stack. |
