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.
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.
An insecure direct object reference vulnerability in GitLab EE affecting all versions from 15.7 prior to 17.6.5, 17.7 prior to 17.7.4, and 17.8 prior to 17.8.2 allows an attacker to view repositories in an unauthorized way.
In all versions of GitLab CE/EE since version 8.0, access tokens created as part of admin's impersonation of a user are not cleared at the end of impersonation which may lead to unnecessary sensitive info disclosure.
An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.9 before 17.0.6, all versions starting from 17.1 before 17.1.4, all versions starting from 17.2 before 17.2.2. Under certain conditions, access tokens may have been logged when an API request was made in a specific manner.
An issue has been discovered in GitLab affecting all versions starting from 11.6. Pull mirror credentials are exposed that allows other maintainers to be able to view the credentials in plain-text,
An issue was discovered in GitLab EE affecting all versions starting from 16.11 prior to 17.0.5, starting from 17.1 prior to 17.1.3, and starting from 17.2 prior to 17.2.1 where certain project-level analytics settings could be leaked in DOM to group members with Developer or higher roles.
An issue has been discovered in GitLab CE/EE affecting all versions before 17.10.7, 17.11 before 17.11.3, and 18.0 before 18.0.1. An attacker may be able to reveal masked or hidden CI variables (that they did not author) in the WebUI, by simply creating their own variable and observing the HTTP response.
An authorization issue in GitLab CE/EE version 9.4 and up allowed a group maintainer to modify group CI/CD variables which should be restricted to group owners
GitLab Enterprise Edition (EE) 9.0 and later through 12.5 allows Information Disclosure.
An issue has been discovered in GitLab CE/EE affecting all versions starting from 12.9 prior to 15.3.5, 15.4 prior to 15.4.4, and 15.5 prior to 15.5.2. A group owner may be able to bypass External Authorization check, if it is enabled, to access git repositories and package registries by using Deploy tokens or Deploy keys .
An information disclosure vulnerability has been discovered in GitLab EE/CE affecting all versions starting from 11.5 before 15.8.5, all versions starting from 15.9 before 15.9.4, all versions starting from 15.10 before 15.10.1 will allow an admin to leak password from repository mirror configuration.
An issue has been discovered in GitLab CE/EE affecting all versions before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1. It may be possible for malicious group or project maintainers to change their corresponding group or project visibility by crafting a malicious POST request.
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.2 before 18.5.5 and 18.6 before 18.6.3 that could have allowed an authenticated user with access to certain logs to obtain sensitive tokens under specific conditions.
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 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.
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 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 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 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.
Information disclosure in Advanced Search component of GitLab EE starting from 8.4 results in exposure of search terms via Rails logs. This affects versions >=8.4 to <13.4.7, >=13.5 to <13.5.5, and >=13.6 to <13.6.2.
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`.
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.
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
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.
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
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.
Dell Networking Switches running Enterprise SONiC OS, version(s) prior to 4.4.1 and 4.2.3, contain(s) an Insertion of Sensitive Information into Log File vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Information exposure.
A vulnerability in the logging component of Cisco TelePresence Collaboration Endpoint (CE) and Cisco RoomOS Software could allow an authenticated, remote attacker to view sensitive information in clear text on an affected system. To exploit this vulnerability, the attacker must have valid administrative credentials. This vulnerability exists because certain unencrypted credentials are stored when SIP media component logging is enabled. An attacker could exploit this vulnerability by accessing the audit logs on an affected system and obtaining credentials to which they may not normally have access. A successful exploit could allow the attacker to use those credentials to access confidential information, some of which may contain personally identifiable information (PII). Note: To access the logs that are stored in the Webex Cloud or stored on the device itself, an attacker must have valid administrative credentials.
Tanium addressed an information disclosure vulnerability in Threat Response.
Brocade SANnav versions before 2.2.2 log Brocade Fabric OS switch passwords when debugging is enabled.
In limited scenarios, sensitive data might be written to the log file if an admin uses Microsoft Teams Admin Center (TAC) to make device configuration changes. The affected log file is visible only to users with admin credentials. This is limited to Microsoft TAC and does not affect configuration changes made using the provisioning server or the device WebUI.
IBM Aspera Console 3.4.7 stores potentially sensitive information in log files that could be read by a local privileged user.
IBM App Connect Enterprise 11.0.0.17 through 11.0.0.19 and 12.0.4.0 and 12.0.5.0 contains an unspecified vulnerability in the Discovery Connector nodes which may cause a 3rd party system’s credentials to be exposed to a privileged attacker. IBM X-Force ID: 238211.
Under certain error conditions at time of SANnav installation or upgrade, the encryption key can be written into and obtained from a Brocade SANnav supportsave. An attacker with privileged access to the Brocade SANnav database could use the encryption key to obtain passwords used by Brocade SANnav.
SAP Web Dispatcher and Internet Communication Manager allow an attacker with administrative privileges to enable debugging trace mode with a specific parameter value. This exposes unencrypted passwords in the logs, causing a high impact on the confidentiality of the application. There is no impact on integrity or availability.
In Search Guard FLX versions from 1.0.0 up to 4.0.1, the audit logging feature might log user credentials from users logging into Kibana.
Valtimo is an open-source business process automation platform. In versions 13.0.0 through 13.21.0, the InboxHandlingService logs the full content of every incoming inbox message at INFO level. Inbox messages can contain highly sensitive information including personal data (PII), citizen identifiers (BSN), and case details. This data is exposed to anyone with access to application logs or any Valtimo user with the admin role through the Admin UI logging module. This issue has been fixed in version 13.22.0. If developers are unable to upgrade immediately, they can restrict access to application logs and adjust the log level for com.ritense.inbox to WARN or higher in their application configuration as a workaround.
Under certain circumstances unnecessary user details are provided within system logs
In Ericsson Network Manager (ENM) releases before 21.2, users belonging to the same AMOS authorization group can retrieve the data from certain log files. All AMOS users are considered to be highly privileged users in ENM system and all must be previously defined and authorized by the Security Administrator. Those users can access some log’s files, under a common path, and read information stored in the log’s files in order to conduct privilege escalation.
Nextcloud Mail is an email application for the nextcloud personal cloud product. Affected versions of Nextcloud mail would log user passwords to disk in the event of a misconfiguration. Should an attacker gain access to the logs complete access to affected accounts would be obtainable. It is recommended that the Nextcloud Mail is upgraded to 1.12.1. Operators should inspect their logs and remove passwords which have been logged. There are no workarounds to prevent logging in the event of a misconfiguration.
Apache NiFi 1.16.0 through 1.28.0 and 2.0.0-M1 through 2.0.0-M4 include optional debug logging of Parameter Context values during the flow synchronization process. An authorized administrator with access to change logging levels could enable debug logging for framework flow synchronization, causing the application to write Parameter names and values to the application log. Parameter Context values may contain sensitive information depending on application flow configuration. Deployments of Apache NiFi with the default Logback configuration do not log Parameter Context values. Upgrading to Apache NiFi 2.0.0 or 1.28.1 is the recommendation mitigation, eliminating Parameter value logging from the flow synchronization process regardless of the Logback configuration.
In Splunk Enterprise versions below 9.3.1, 9.2.3, and 9.1.6, the software potentially exposes sensitive HTTP parameters to the `_internal` index. This exposure could happen if you configure the Splunk Enterprise `REST_Calls` log channel at the DEBUG logging level.
Pimcore is an Open Source Data & Experience Management Platform. Prior to 12.3.1 and 11.5.14, the http_error_log file stores the $_COOKIE and $_SERVER variables, which means sensitive information such as database passwords, cookie session data, and other details can be accessed or recovered through the Pimcore backend. This vulnerability is fixed in 12.3.1 and 11.5.14.
A flaw was discovered in bolt-server and ace where running a task with sensitive parameters results in those sensitive parameters being logged when they should not be. This issue only affects SSH/WinRM nodes (inventory service nodes).
Insertion of debug information into log file during building the elastic search index allows reading of sensitive information from articles.This issue affects OTRS: from 7.0.X through 7.0.48, from 8.0.X through 8.0.37, from 2023.X through 2023.1.1.
Dell EMC AppSync, versions from 4.2.0.0 to 4.6.0.0 including all Service Pack releases, contain an exposure of sensitive information vulnerability in AppSync server logs. A high privileged remote attacker could potentially exploit this vulnerability, leading to the disclosure of certain user credentials. The attacker may be able to use the exposed credentials to access the vulnerable system with privileges of the compromised account.
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.
In Splunk Enterprise versions below 10.2.0, 10.0.2, 9.4.7, 9.3.9, and 9.2.11, a user of a Splunk Search Head Cluster (SHC) deployment who holds a role with access to the Splunk `_internal` index could view the RSA `accessKey` value from the [<u>Authentication.conf</u> ](https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.2/configuration-file-reference/10.2.0-configuration-file-reference/authentication.conf)file, in plain text.