Windows Kernel Memory Information Disclosure Vulnerability
Windows Kernel Memory Information Disclosure Vulnerability
Windows Kernel Memory Information Disclosure Vulnerability
ydb-go-sdk is a pure Go native and database/sql driver for the YDB platform. Since ydb-go-sdk v3.48.6 if you use a custom credentials object (implementation of interface Credentials it may leak into logs. This happens because this object could be serialized into an error message using `fmt.Errorf("something went wrong (credentials: %q)", credentials)` during connection to the YDB server. If such logging occurred, a malicious user with access to logs could read sensitive information (i.e. credentials) information and use it to get access to the database. ydb-go-sdk contains this problem in versions from v3.48.6 to v3.53.2. The fix for this problem has been released in version v3.53.3. Users are advised to upgrade. Users unable to upgrade should implement the `fmt.Stringer` interface in your custom credentials type with explicit stringify of object state.
Sensitive information leak through log files. The following products are affected: Acronis Cyber Protect Home Office (Windows) before build 40107.
IBM UrbanCode Deploy (UCD) through 7.1.2.21, 7.2 through 7.2.3.14, and 7.3 through 7.3.2.0 / IBM DevOps Deploy 8.0 through 8.0.1.4 and 8.1 through 8.1 stores potentially sensitive authentication token information in log files that could be read by a local user.
Dell PowerScale OneFS, 9.0.0.x-9.4.0.x, contain a cleartext storage of sensitive information vulnerability in S3 component. An authenticated local attacker could potentially exploit this vulnerability, leading to information disclosure.
When TACACS+ audit forwarding is configured on BIG-IP or BIG-IQ system, sharedsecret is logged in plaintext in the audit log. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
A flaw was found in ansible module where credentials are disclosed in the console log by default and not protected by the security feature when using the bitbucket_pipeline_variable module. This flaw allows an attacker to steal bitbucket_pipeline credentials. The highest threat from this vulnerability is to confidentiality.
An access-control flaw was found in the OpenStack Orchestration (heat) service before 8.0.0, 6.1.0 and 7.0.2 where a service log directory was improperly made world readable. A malicious system user could exploit this flaw to access sensitive information.
Under certain circumstances a user's password may be logged in cleartext in the PanGPS.log diagnostic file when logs are collected for troubleshooting on GlobalProtect app (also known as GlobalProtect Agent) for MacOS and Windows. For this issue to occur all of these conditions must be true: (1) 'Save User Credential' option should be set to 'Yes' in the GlobalProtect Portal's Agent configuration, (2) the GlobalProtect user manually selects a gateway, (3) and the logging level is set to 'Dump' while collecting troubleshooting logs. This issue does not affect GlobalProtect app on other platforms (for example iOS/Android/Linux). This issue affects GlobalProtect app 5.0 versions earlier than 5.0.9, GlobalProtect app 5.1 versions earlier than 5.1.2 on Windows or MacOS. Since becoming aware of the issue, Palo Alto Networks has safely deleted all the known GlobalProtectLogs zip files sent by customers with the credentials. We now filter and remove these credentials from all files sent to Customer Support. The GlobalProtectLogs zip files uploaded to Palo Alto Networks systems were only accessible by authorized personnel with valid Palo Alto Networks credentials. We do not have any evidence of malicious access or use of these credentials.
In JetBrains YouTrack before 2024.3.55417 permanent tokens could be exposed in logs
IBM Robotic Process Automation with Automation Anywhere 11 could allow a local user to obtain highly sensitive information from log files when debugging is enabled. IBM X-Force ID: 160765.
IBM Maximo Application Suite - Maximo Mobile for EAM 8.10 and 8.11 could disclose sensitive information to a local user. IBM X-Force ID: 266875.
Kubernetes secrets-store-csi-driver in versions before 1.3.3 discloses service account tokens in logs.
When on BIG-IP DNS or BIG-IP LTM enabled with DNS Services License, and a TSIG key is created, it is logged in plaintext in the audit log. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
A security flaw was found in Ansible Engine, all Ansible 2.7.x versions prior to 2.7.17, all Ansible 2.8.x versions prior to 2.8.11 and all Ansible 2.9.x versions prior to 2.9.7, when managing kubernetes using the k8s module. Sensitive parameters such as passwords and tokens are passed to kubectl from the command line, not using an environment variable or an input configuration file. This will disclose passwords and tokens from process list and no_log directive from debug module would not have any effect making these secrets being disclosed on stdout and log files.
A flaw was found in keycloak in versions before 9.0.0. A logged exception in the HttpMethod class may leak the password given as parameter. The highest threat from this vulnerability is to data confidentiality.
A local, authenticated user with shell can obtain the hashed values of login passwords via configd traces. This issue affects all versions of Junos OS Evolved prior to 19.3R1.
A local, authenticated user with shell can obtain the hashed values of login passwords via configd streamer log. This issue affects all versions of Junos OS Evolved prior to 19.3R1.
A local, authenticated user with shell can obtain the hashed values of login passwords and shared secrets via the EvoSharedObjStore. This issue affects all versions of Junos OS Evolved prior to 19.1R1.
A local, authenticated user with shell can obtain the hashed values of login passwords and shared secrets via raw objmon configuration files. This issue affects all versions of Junos OS Evolved prior to 19.1R1.
A local, authenticated user with shell can view sensitive configuration information via the ev.ops configuration file. This issue affects all versions of Junos OS Evolved prior to 19.2R1.
IBM Maximo Application Suite 8.8.0 and 8.9.0 stores potentially sensitive information that could be read by a local user. IBM X-Force ID: 241584.
An Improper Output Neutralization for Logs flaw was found in Ansible when using the uri module, where sensitive data is exposed to content and json output. This flaw allows an attacker to access the logs or outputs of performed tasks to read keys used in playbooks from other users within the uri module. The highest threat from this vulnerability is to data confidentiality.
On Juniper ATP, the API key and the device key are logged in a file readable by authenticated local users. These keys are used for performing critical operations on the WebUI interface. This issue affects Juniper ATP 5.0 versions prior to 5.0.3.
Hitachi Ops Center Common Services within Hitachi Ops Center OVA contains an information exposure vulnerability. This issue affects Hitachi Ops Center Common Services: from 11.0.3-00 before 11.0.4-00.
In versions bundled with BIG-IP APM 12.1.0-12.1.5 and 11.6.1-11.6.5.2, Edge Client for Linux exposes full session ID in the local log files.
The Hashicorp go-getter library before 1.5.11 does not redact an SSH key from a URL query parameter.
This advisory documents an internally found vulnerability in the on premises deployment model of Arista CloudVision Portal (CVP) where under a certain set of conditions, user passwords can be leaked in the Audit and System logs. The impact of this vulnerability is that the CVP user login passwords might be leaked to other authenticated users.
IBM Business Automation Workflow 19.0.0.3 stores potentially sensitive information in log files that could be read by a local user. IBM X-Force ID: 190991.
Windows Kernel Memory Information Disclosure Vulnerability
Windows Kernel Memory Information Disclosure Vulnerability
Windows Kernel Memory Information Disclosure Vulnerability
Windows Kernel Memory Information Disclosure Vulnerability
A Inclusion of Sensitive Information in Log Files vulnerability in yast2-rmt of SUSE Linux Enterprise Server 15; openSUSE Leap allows local attackers to learn the password if they can access the log file. This issue affects: SUSE Linux Enterprise Server 15 yast2-rmt versions prior to 1.2.2. openSUSE Leap yast2-rmt versions prior to 1.2.2.
An issue in Archer Platform before v.6.13 fixed in v.6.12.0.6 and v.6.13.0 allows an authenticated attacker to obtain sensitive information via the log files.
Sensitive information written to a log file vulnerability was found in jaegertracing/jaeger before version 1.18.1 when the Kafka data store is used. This flaw allows an attacker with access to the container's log file to discover the Kafka credentials.
Possible information exposure through log file vulnerability where sensitive fields are recorded in the debug-enabled logs when debugging is turned on in Brocade SANnav before 2.3.0 and 2.2.2a
An information-disclosure flaw was found in the way that gluster-block before 0.5.1 logs the output from gluster-block CLI operations. This includes recording passwords to the cmd_history.log file which is world-readable. This flaw allows local users to obtain sensitive information by reading the log file. The highest threat from this vulnerability is to data confidentiality.
A vulnerability has been identified in SIMATIC RTLS Locating Manager (All versions < V2.12). The affected application writes sensitive data, such as usernames and passwords in log files. A local attacker with access to the log files could use this information to launch further attacks.
A flaw was found in Infinispan, when using JGroups with JDBC_PING. This issue occurs when an application inadvertently exposes sensitive information, such as configuration details or credentials, through logging mechanisms. This exposure can lead to unauthorized access and exploitation by malicious actors.
Insertion of Sensitive Information into Log File vulnerability in Hitachi Ops Center Administrator on Linux allows local users to gain sensitive information.This issue affects Hitachi Ops Center Administrator: before 10.9.3-00.
Dell Wyse ThinOS versions prior to 2303 (9.4.1141) contain a sensitive information disclosure vulnerability. An unauthenticated malicious user with local access to the device could exploit this vulnerability to read sensitive information written to the log files.
Dell Wyse ThinOS versions prior to 2306 (9.4.2103) contain a sensitive information disclosure vulnerability. A malicious user with local access to the device could exploit this vulnerability to read sensitive information written to the log files.
Insertion of sensitive information into log file in some Intel(R) On Demand software before versions 1.16.2, 2.1.1, 3.1.0 may allow an authenticated user to potentially enable information disclosure via local access.
Dell Wyse ThinOS versions prior to 2208 (9.3.2102) contain a sensitive information disclosure vulnerability. An unauthenticated malicious user with local access to the device could exploit this vulnerability to read sensitive information written to the log files.
Filebeat versions through 7.17.9 and 8.6.2 have a flaw in httpjson input that allows the http request Authorization or Proxy-Authorization header contents to be leaked in the logs when debug logging is enabled.
Transmission of credentials within query parameters in Checkmk <= 2.1.0p26, <= 2.0.0p35, and <= 2.2.0b6 (beta) may cause the automation user's secret to be written to the site Apache access log.
aws-sigv4 is a rust library for low level request signing in the aws cloud platform. The `aws_sigv4::SigningParams` struct had a derived `Debug` implementation. When debug-formatted, it would include a user's AWS access key, AWS secret key, and security token in plaintext. When TRACE-level logging is enabled for an SDK, `SigningParams` is printed, thereby revealing those credentials to anyone with access to logs. All users of the AWS SDK for Rust who enabled TRACE-level logging, either globally (e.g. `RUST_LOG=trace`), or for the `aws-sigv4` crate specifically are affected. This issue has been addressed in a set of new releases. Users are advised to upgrade. Users unable to upgrade should disable TRACE-level logging for AWS Rust SDK crates.