Accidental logging of system root password in the migration log in all versions of GitLab CE/EE before 14.2.6, all versions starting from 14.3 before 14.3.4, and all versions starting from 14.4 before 14.4.1 allows an attacker with local file system access to obtain system root-level privileges

An information disclosure issue in GitLab starting from version 12.8 allowed a user with access to the server logs to see sensitive information that wasn't properly redacted.

In all versions of GitLab, marshalled session keys were being stored in Redis.

In all versions of GitLab CE/EE starting version 14.0 before 14.3.6, all versions starting from 14.4 before 14.4.4, all versions starting from 14.5 before 14.5.2, the reset password token and new user email token are accidentally logged which may lead to information disclosure.

A vulnerability in the internal Kubernetes agent api in GitLab CE/EE version 13.3 and above allows unauthorized access to private projects. Affected versions are: >=13.4, <13.4.5,>=13.3, <13.3.9,>=13.5, <13.5.2.

An issue has been discovered in GitLab affecting all versions prior to 13.2.10, 13.3.7 and 13.4.2. Sessions keys are stored in plain-text in Redis which allows attacker with Redis access to authenticate as any user that has a session stored in Redis

When importing repos via URL, one time use git credentials were persisted beyond the expected time window in Gitaly 1.79.0 or above.

GitLab EE/CE 8.5 to 12.9 is vulnerable to a an path traversal when moving an issue between projects.

An issue was discovered in GitLab Community and Enterprise Edition before 11.6.10, 11.7.x before 11.7.6, and 11.8.x before 11.8.1. It has Incorrect Access Control (issue 3 of 5).

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.

GitLab CE/EE, versions 8.0 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, would log access tokens in the Workhorse logs, permitting administrators with access to the logs to see another user's token.

An issue was discovered in GitLab Community and Enterprise Edition before 11.0.6, 11.1.x before 11.1.5, and 11.2.x before 11.2.2. There is Sensitive Data Disclosure in Sidekiq Logs through an Error Message.

An issue was discovered in GitLab EE affecting all versions starting from 17.0 prior to 17.0.6, starting from 17.1 prior to 17.1.4, and starting from 17.2 prior to 17.2.2, where webhook deletion audit log preserved auth credentials.

An information disclosure issue in Gitlab CE/EE affecting all versions from 13.6 prior to 15.11.10, all versions from 16.0 prior to 16.0.6, all versions from 16.1 prior to 16.1.1, resulted in the Sidekiq log including webhook tokens when the log format was set to `default`.

Email addresses were leaked in WebHook logs in GitLab EE affecting all versions from 9.3 prior to 15.2.5, 15.3 prior to 15.3.4, and 15.4 prior to 15.4.1

An issue was discovered in GitLab CE/EE affecting all versions starting from 16.5 prior to 17.1.7, starting from 17.2 prior to 17.2.5, and starting from 17.3 prior to 17.3.2, where dependency proxy credentials are retained in graphql Logs.

An information disclosure vulnerability in GitLab CE/EE affecting all versions starting from 9.3 before 15.2.5, all versions starting from 15.3 before 15.3.4, all versions starting from 15.4 before 15.4.1 allows a project maintainer to access the DataDog integration API key from webhook logs.

An issue has been discovered in GitLab EE affecting all versions starting from 14.3 before 16.0.8, all versions starting from 16.1 before 16.1.3, all versions starting from 16.2 before 16.2.2. Access tokens may have been logged when a query was made to a specific endpoint.

Missing sanitization of logged exception messages in all versions prior to 14.7.7, 14.8 prior to 14.8.5, and 14.9 prior to 14.9.2 of GitLab CE/EE causes potential sensitive values in invalid URLs to be logged

Information disclosure from SendEntry in GitLab starting with 10.8 allowed exposure of full URL of artifacts stored in object-storage with a temporary availability via Rails logs.

An issue was discovered in GitLab Community and Enterprise Edition 9.x, 10.x, and 11.x before 11.8.9, 11.9.x before 11.9.10, and 11.10.x before 11.10.2. Gitaly has allows an information disclosure issue where HTTP/GIT credentials are included in logs on connection errors.

An issue has been discovered in GitLab affecting all versions starting from 9.3 before 15.4.6, all versions starting from 15.5 before 15.5.5, all versions starting from 15.6 before 15.6.1. It was possible for a project maintainer to unmask webhook secret tokens by reviewing the logs after testing webhooks.

All versions of GitLab CE/EE starting from 9.5 before 13.10.5, all versions starting from 13.11 before 13.11.5, and all versions starting from 13.12 before 13.12.2 allow a high privilege user to obtain sensitive information from log files because the sensitive information was not correctly registered for log masking.

On Juniper ATP, secret passphrase CLI inputs, such as "set mcm", are logged to /var/log/syslog in clear text, allowing authenticated local user to be able to view these secret information. This issue affects Juniper ATP 5.0 versions prior to 5.0.4.

Exposure of Sensitive Information vulnerability in Fingerprint TA prior to SMR Feb-2023 Release 1 allows attackers to access the memory address information via log.

In User Backup Manager, there is a possible way to leak a token to bypass user confirmation for backup due to log information disclosure. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.

Juniper ATP Series Splunk credentials are logged in a file readable by authenticated local users. Using these credentials an attacker can access the Splunk server. This issue affects Juniper ATP 5.0 versions prior to 5.0.3.

A password management issue exists where the Organization authentication username and password were stored in plaintext in log files. A locally authenticated attacker who is able to access these stored plaintext credentials can use them to login to the Organization. Affected products are: Juniper Networks Service Insight versions from 15.1R1, prior to 18.1R1. Service Now versions from 15.1R1, prior to 18.1R1.

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.

The destroy_one_secret function in nm-setting-vpn.c in libnm-util in the NetworkManager package 0.8.999-3.git20110526 in Fedora 15 creates a log entry containing a certificate password, which allows local users to obtain sensitive information by reading a log file.

VMware Horizon View Agents (7.x.x before 7.5.1) contain a local information disclosure vulnerability due to insecure logging of credentials in the vmmsi.log file when an account other than the currently logged on user is specified during installation (including silent installations). Successful exploitation of this issue may allow low privileged users access to the credentials specified during the Horizon View Agent installation.

The aoedisk_debugfs_show function in drivers/block/aoe/aoeblk.c in the Linux kernel through 4.16.4rc4 allows local users to obtain sensitive address information by reading "ffree: " lines in a debugfs file.

Brocade SANnav before Brocade SANnav 2.4.0a could log database passwords in clear text in audit logs when the daily data dump collector invokes docker exec commands. These audit logs are the local server VM’s audit logs and are not controlled by SANnav. These logs are only visible to the server admin of the host server and are not visible to the SANnav admin or any SANnav user.

An issue was discovered on Orbic Wonder Orbic/RC555L/RC555L:7.1.2/N2G47H/329100b:user/release-keys devices, allowing attackers to obtain sensitive information (such as text-message content) by reading a copy of the Android log on the SD card. The system-wide Android logs are not directly available to third-party apps since they tend to contain sensitive data. Third-party apps can read from the log but only the log messages that the app itself has written. Certain apps can leak data to the Android log due to not sanitizing log messages, which is in an insecure programming practice. Pre-installed system apps and apps that are signed with the framework key can read from the system-wide Android log. We found a pre-installed app on the Orbic Wonder that when started via an Intent will write the Android log to the SD card, also known as external storage, via com.ckt.mmitest.MmiMainActivity. Any app that requests the READ_EXTERNAL_STORAGE permission can read from the SD card. Therefore, a local app on the device can quickly start a specific component in the pre-installed system app to have the Android log written to the SD card. Therefore, any app co-located on the device with the READ_EXTERNAL_STORAGE permission can obtain the data contained within the Android log and continually monitor it and mine the log for relevant data. In addition, the default messaging app (com.android.mms) writes the body of sent and received text messages to the Android log, as well as the recipient phone number for sent text messages and the sending phone number for received text messages. In addition, any call data contains phone numbers for sent and received calls.

Insertion of Sensitive Information into Log Files in M-Files Server before 22.10.11846.0 could allow to obtain sensitive tokens from logs, if specific configurations were set.

IBM Tivoli Endpoint Manager - Mobile Device Management (MDM) stores potentially sensitive information in log files that could be available to a local user.

The LinuxMagic MagicSpam extension before 2.0.14-1 for Plesk allows local users to discover mailbox names by reading /var/log/magicspam/mslog.

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.

There is an information leakage vulnerability in FusionCompute 6.5.1, eCNS280_TD V100R005C00 and V100R005C10. Due to the improperly storage of specific information in the log file, the attacker can obtain the information when a user logs in to the device. Successful exploit may cause the information leak.

Swann SWWHD-INTCAM-HD devices leave the PSK in logs after a factory reset. NOTE: all affected customers were migrated by 2020-08-31.

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.

Dell EMC SCG 5.00.00.10 and earlier, contain a sensitive information disclosure vulnerability. A local malicious user may exploit this vulnerability to read sensitive information and use it.

Dell EMC PowerScale OneFS versions 8.2.x, 9.1.0.x, and 9.1.1.1 contain a sensitive information exposure vulnerability in log files. A local malicious user with ISI_PRIV_LOGIN_SSH, ISI_PRIV_LOGIN_CONSOLE, or ISI_PRIV_SYS_SUPPORT privileges may exploit this vulnerability to access sensitive information. If any third-party consumes those logs, the same sensitive information is available to those systems as well.

Insertion of Sensitive Information into Log File vulnerabilities are affecting DELMIA Apriso Release 2019 through Release 2024

Insertion of Sensitive Information into Log File vulnerability in Hitachi Ops Center Administrator allows local users to gain sensitive information.This issue affects Hitachi Ops Center Administrator: before 11.0.1.

A potential logging of the firestore key via logging within nodejs-firestore exists - Developers who were logging objects through this._settings would be logging the firestore key as well potentially exposing it to anyone with logs read access. We recommend upgrading to version 6.1.0 to avoid this issue

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.

Under certain circumstances SAP Dynamic Authorization Management (DAM) by NextLabs (Java Policy Controller versions 7.7 and 8.5) exposes sensitive information in the application logs.

iDrive RemotePC before 7.6.48 on Windows allows information disclosure. A locally authenticated attacker can read the system's Personal Key in world-readable %PROGRAMDATA% log files.

IBM Spectrum Protect Server 7.1 and 8.1 could disclose highly sensitive information via trace logs to a local privileged user. IBM X-Force ID: 148873.