| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Directus is a real-time API and App dashboard for managing SQL database content. Starting in version 9.0.0 and prior to version 11.9.0, when using Directus Flows with the WebHook trigger all incoming request details are logged including security sensitive data like access and refresh tokens in cookies. Malicious admins with access to the logs can hijack the user sessions within the token expiration time of them triggering the Flow. Version 11.9.0 fixes the issue. |
| Directus is a real-time API and App dashboard for managing SQL database content. Starting in version 9.0.0 and prior to version 11.9.0, when using Directus Flows to handle CRUD events for users it is possible to log the incoming data to console using the "Log to Console" operation and a template string. Malicious admins can log sensitive data from other users when they are created or updated. Version 11.9.0 contains a fix for the issue. As a workaround, avoid logging sensitive data to the console outside the context of development. |
| Apache Pulsar contains multiple connectors for integrating with Apache Kafka. The Pulsar IO Apache Kafka Source Connector, Sink Connector, and Kafka Connect Adaptor Sink Connector log sensitive configuration properties in plain text in application logs.
This vulnerability can lead to unintended exposure of credentials in log files, potentially allowing attackers with access to these logs to obtain Apache Kafka credentials. The vulnerability's impact is limited by the fact that an attacker would need access to the application logs to exploit this issue.
This issue affects Apache Pulsar IO's Apache Kafka connectors in all versions before 3.0.11, 3.3.6, and 4.0.4.
3.0.x version users should upgrade to at least 3.0.11.
3.3.x version users should upgrade to at least 3.3.6.
4.0.x version users should upgrade to at least 4.0.4.
Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. |
| Insertion of sensitive information into a log file in Ivanti Connect Secure before version 22.7R2.8 and Ivanti Policy Secure before version 22.7R1.5 allows a local authenticated attacker to obtain that information. |
| Insertion of sensitive information into a log file in Ivanti Connect Secure before version 22.7R2.8 allows a local authenticated attacker to obtain that information. |
| Insertion of Sensitive Information into Log File vulnerability in Apache ActiveMQ Artemis. All the values of the broker properties are logged when the org.apache.activemq.artemis.core.config.impl.ConfigurationImpl logger has the debug level enabled.
This issue affects Apache ActiveMQ Artemis: from 1.5.1 before 2.40.0. It can be mitigated by restricting log access to only trusted users.
Users are recommended to upgrade to version 2.40.0, which fixes the issue. |
| An issue was discovered in GitLab CE/EE affecting all versions starting from 11.0 prior to 17.4.6, starting from 17.5 prior to 17.5.4, and starting from 17.6 prior to 17.6.2, where sensitive information passed in GraphQL mutations may have been retained in GraphQL logs. |
| Exposure of Sensitive Information to an Unauthorized Actor, Insertion of Sensitive Information into Log File vulnerability in Apache IoTDB JDBC driver.
This issue affects iotdb-jdbc: from 0.10.0 through 1.3.3, from 2.0.1-beta before 2.0.2.
Users are recommended to upgrade to version 2.0.2 and 1.3.4, which fix the issue. |
| Cloud Foundry UAA release versions from v77.21.0 to v7.31.0 are vulnerable to a private key exposure in logs. |
| Exposure of temporary credentials in logs in Apache Arrow Rust Object Store (`object_store` crate), version 0.10.1 and earlier on all platforms using AWS WebIdentityTokens.
On certain error conditions, the logs may contain the OIDC token passed to AssumeRoleWithWebIdentity https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html . This allows someone with access to the logs to impersonate that identity, including performing their own calls to AssumeRoleWithWebIdentity, until the OIDC token expires. Typically OIDC tokens are valid for up to an hour, although this will vary depending on the issuer.
Users are recommended to use a different AWS authentication mechanism, disable logging or upgrade to version 0.10.2, which fixes this issue.
Details:
When using AWS WebIdentityTokens with the object_store crate, in the event of a failure and automatic retry, the underlying reqwest error, including the full URL with the credentials, potentially in the parameters, is written to the logs.
Thanks to Paul Hatcherian for reporting this vulnerability |
| Versions of the package snyk before 1.1297.3 are vulnerable to Insertion of Sensitive Information into Log File through local Snyk CLI debug logs. Container Registry credentials provided via environment variables or command line arguments can be exposed when executing Snyk CLI in DEBUG or DEBUG/TRACE mode.
The issue affects the following Snyk commands:
1. When snyk container test or snyk container monitor commands are run against a container registry, with debug mode enabled, the container registry credentials may be written into the local Snyk CLI debug log. This only happens with credentials specified in environment variables (SNYK_REGISTRY_USERNAME and SNYK_REGISTRY_PASSWORD), or in the CLI (--password/-p and --username/-u).
2. When snyk auth command is executed with debug mode enabled AND the log level is set to TRACE, the Snyk access / refresh credential tokens used to connect the CLI to Snyk may be written into the local CLI debug logs.
3. When snyk iac test is executed with a Remote IAC Custom rules bundle, debug mode enabled, AND the log level is set to TRACE, the docker registry token may be written into the local CLI debug logs. |
| Exposure of Sensitive Information to an Unauthorized Actor, Insertion of Sensitive Information into Log File vulnerability in the OpenIdAuthorizer of Apache IoTDB.
This issue affects Apache IoTDB: from 0.10.0 through 1.3.3, from 2.0.1-beta before 2.0.2.
Users are recommended to upgrade to version 1.3.4 and 2.0.2, which fix the issue. |
| System->Maintenance-> Log Files in dotCMS dashboard is providing the username/password for database connections in the log output. Nevertheless, this is a moderate issue as it requires a backend admin as well as that dbs are locked down by environment.
OWASP Top 10 - A05) Insecure Design
OWASP Top 10 - A05) Security Misconfiguration
OWASP Top 10 - A09) Security Logging and Monitoring Failure |
| iTerm2 3.5.6 through 3.5.10 before 3.5.11 sometimes allows remote attackers to obtain sensitive information from terminal commands by reading the /tmp/framer.txt file. This can occur for certain it2ssh and SSH Integration configurations, during remote logins to hosts that have a common Python installation. |
| A vulnerability, which was classified as problematic, has been found in China Unicom TEWA-800G 4.16L.04_CT2015_Yueme. Affected by this issue is some unknown functionality. The manipulation leads to information exposure through debug log file. It is possible to launch the attack on the physical device. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. VDB-239870 is the identifier assigned to this vulnerability. |
| Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator.
This issue affects all versions of the Apache Solr Operator from 0.3.0 through 0.8.0.
When asked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the "solr" and "admin" accounts for use by end-users, and a "k8s-oper" account which the operator uses for its own requests to Solr.
One common source of these operator requests is healthchecks: liveness, readiness, and startup probes are all used to determine Solr's health and ability to receive traffic.
By default, the operator configures the Solr APIs used for these probes to be exempt from authentication, but users may specifically request that authentication be required on probe endpoints as well.
Whenever one of these probes would fail, if authentication was in use, the Solr Operator would create a Kubernetes "event" containing the username and password of the "k8s-oper" account.
Within the affected version range, this vulnerability affects any solrcloud resource which (1) bootstrapped security through use of the `.solrOptions.security.authenticationType=basic` option, and (2) required authentication be used on probes by setting `.solrOptions.security.probesRequireAuth=true`.
Users are recommended to upgrade to Solr Operator version 0.8.1, which fixes this issue by ensuring that probes no longer print the credentials used for Solr requests. Users may also mitigate the vulnerability by disabling authentication on their healthcheck probes using the setting `.solrOptions.security.probesRequireAuth=false`. |
| An issue was discovered in the AbuseFilter extension for MediaWiki before 1.39.9, 1.40.x and 1.41.x before 1.41.3, and 1.42.x before 1.42.2. An API caller can match a filter condition against AbuseFilter logs even if the caller is not authorized to view the log details for the filter. |
| react-native-mmkv is a library that allows easy use of MMKV inside React Native applications. Before version 2.11.0, the react-native-mmkv logged the optional encryption key for the MMKV database into the Android system log. The key can be obtained by anyone with access to the Android Debugging Bridge (ADB) if it is enabled in the phone settings. This bug is not present on iOS devices. By logging the encryption secret to the system logs, attackers can trivially recover the secret by enabling ADB and undermining an app's thread model. This issue has been patched in version 2.11.0. |
| Insertion of Sensitive Information into Log File vulnerability in Apache Airflow Celery provider, Apache Airflow.
Sensitive information logged as clear text when rediss, amqp, rpc protocols are used as Celery result backend
Note: the vulnerability is about the information exposed in the logs not about accessing the logs.
This issue affects Apache Airflow Celery provider: from 3.3.0 through 3.4.0; Apache Airflow: from 1.10.0 through 2.6.3.
Users are recommended to upgrade Airflow Celery provider to version 3.4.1 and Apache Airlfow to version 2.7.0 which fixes the issue. |
| A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in macOS Sonoma 14, macOS Monterey 12.7.1. An app with root privileges may be able to access private information. |
