An issue has been discovered in GitLab CE/EE affecting all versions starting with 14.5. Arbitrary file read was possible by importing a group was due to incorrect handling of file.

An issue has been discovered in GitLab affecting all versions starting from 14.6 before 14.6.5, all versions starting from 14.7 before 14.7.4, all versions starting from 14.8 before 14.8.2. GitLab was leaking user passwords when adding mirrors with SSH credentials under specific conditions.

Improper input validation in all versions of GitLab CE/EE using sendmail to send emails allowed an attacker to steal environment variables via specially crafted email addresses.

An issue was discovered in GitLab Community Edition (CE) and Enterprise Edition (EE) before 12.7.9, 12.8.x before 12.8.9, and 12.9.x before 12.9.3. A Workhorse bypass could lead to NuGet package and file disclosure (Exposure of Sensitive Information) via request smuggling.

In GitLab EE 11.7 through 12.9, the NPM feature is vulnerable to a path traversal issue.

GitLab EE/CE 8.17 to 12.9 is vulnerable to information leakage when querying a merge request widget.

GitLab before 12.8.2 allows Information Disclosure. Badge images were not being proxied, causing mixed content warnings as well as leaking the IP address of the user.

An issue was discovered in GitLab Community and Enterprise Edition before 11.5.8, 11.6.x before 11.6.6, and 11.7.x before 11.7.1. It allows Information Disclosure (issue 3 of 6). For installations using GitHub or Bitbucket OAuth integrations, it is possible to use a covert redirect to obtain the user OAuth token for those services.

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 affecting all versions starting from 16.2 before 16.2.8, all versions starting from 16.3 before 16.3.5, all versions starting from 16.4 before 16.4.1. It was possible to read the source code of a project through a fork created before changing visibility to only project members.

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.

An information disclosure vulnerability in GitLab EE versions 13.11 and later allowed a project owner to leak information about the members' on-call rotations in other projects

An issue has been discovered in GitLab CE/EE affecting all versions starting with 12.6. Under a special condition it was possible to access data of an internal repository through a public project fork as an anonymous user.

Assuming a database breach, nonce reuse issues in GitLab 11.6+ allows an attacker to decrypt some of the database's encrypted content

An issue has been discovered in GitLab CE/EE affecting all versions starting with 12.8. Under a special condition it was possible to access data of an internal repository through project fork done by a project member.

GitLab EE 8.0 through 12.7.2 has Incorrect Access Control.

An issue was discovered in GitLab Community and Enterprise Edition before 11.5.8, 11.6.x before 11.6.6, and 11.7.x before 11.7.1. It allows Information Disclosure (issue 1 of 6). An authorization issue allows the contributed project information of a private profile to be viewed.

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.

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 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.

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.

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 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.

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

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 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`.

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 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.

A vulnerability has been identified in CP-8000 MASTER MODULE WITH I/O -25/+70°C (All versions < V16.20), CP-8000 MASTER MODULE WITH I/O -40/+70°C (All versions < V16.20), CP-8021 MASTER MODULE (All versions < V16.20), CP-8022 MASTER MODULE WITH GPRS (All versions < V16.20). The web server of the affected system allows access to logfiles and diagnostic data generated by a privileged user. An unauthenticated attacker could access the files by knowing the corresponding download links.

AnyDesk through 8.1.0 on Windows, when Allow Direct Connections is enabled, inadvertently exposes a public IP address within network traffic. The attacker must know the victim's AnyDesk ID.

IBM Security Guardium Key Lifecycle Manager 4.1, 4.1.1, 4.2.0, and 4.2.1 stores potentially sensitive information in log files that could be read by a local privileged user.

The N-able PassPortal extension before 3.29.2 for Chrome inserts sensitive information into a log file.

The web server Monkeyd produces a world-readable log (/var/log/monkeyd/master.log) on gentoo.

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

In Splunk Add-on Builder versions below 4.1.4, the app writes sensitive information to internal log files.

Mattermost 6.0.2 and earlier fails to sufficiently sanitize user's password in audit logs when user creation fails.

Incorrect Access Control issue discovered in tpcms 3.2 allows remote attackers to view sensitive information via path in application URL.

Incorrect Access Control in Zammad 1.0.x up to 4.0.0 allows attackers to obtain sensitive information via email connection configuration probing.

Apache Geode versions up to 1.12.4 and 1.13.4 are vulnerable to a log file redaction of sensitive information flaw when using values that begin with characters other than letters or numbers for passwords and security properties with the prefix "sysprop-", "javax.net.ssl", or "security-". This issue is fixed by overhauling the log file redaction in Apache Geode versions 1.12.5, 1.13.5, and 1.14.0.

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.

apko is an apk-based OCI image builder. apko exposures HTTP basic auth credentials from repository and keyring URLs in log output. This vulnerability is fixed in v0.14.5.

Some MongoDB Drivers may erroneously publish events containing authentication-related data to a command listener configured by an application. The published events may contain security-sensitive data when specific authentication-related commands are executed. Without due care, an application may inadvertently expose this sensitive information, e.g., by writing it to a log file. This issue only arises if an application enables the command listener feature (this is not enabled by default). This issue affects the MongoDB C Driver 1.0.0 prior to 1.17.7, MongoDB PHP Driver 1.0.0 prior to 1.9.2, MongoDB Swift Driver 1.0.0 prior to 1.1.1, MongoDB Node.js Driver 3.6 prior to 3.6.10, MongoDB Node.js Driver 4.0 prior to 4.17.0 and MongoDB Node.js Driver 5.0 prior to 5.8.0. This issue also affects users of the MongoDB C++ Driver dependent on the C driver 1.0.0 prior to 1.17.7 (C++ driver prior to 3.7.0).

Insertion of Sensitive Information into Log File vulnerability in Ghost Foundation Ghost.This issue affects Ghost: from n/a through 1.4.0.

spaces_plugin/app.py in SolidUI 0.4.0 has an unnecessary print statement for an OpenAI key. The printed string might be logged.

Insertion of Sensitive Information into Log File vulnerability in Solid Plugins Solid Affiliate.This issue affects Solid Affiliate: from n/a through 1.9.1.

Insertion of Sensitive Information into Log File vulnerability in Newsletters.This issue affects Newsletters: from n/a through 4.9.5.

Power Platform Terraform Provider allows managing environments and other resources within Power Platform. Versions prior to 3.0.0 have an issue in the Power Platform Terraform Provider where sensitive information, specifically the `client_secret` used in the service principal authentication, may be exposed in logs. This exposure occurs due to an error in the logging code that causes the `client_secret` to not be properly masked when logs are persisted or viewed. Users should upgrade to version 3.0.0 to receive a patched version of the provider that removes all logging of sensitive content. Users who have used this provider with the affected versions should take the following additional steps to mitigate the risk: Immediately rotate the `client_secret` for any service principal that has been configured using this Terraform provider. This will invalidate any potentially exposed secrets. Those who have set the `TF_LOG_PATH` environment variable or configured Terraform to persist logs to a file or an external system, consider disabling this until they have updated to a fixed version of the provider. Those who have existing logs that may contain the `client_secret` should remove or sanitize these logs to prevent unauthorized access. This includes logs on disk, in monitoring systems, or in logging services.

Insertion of Sensitive Information into Log File vulnerability in Searchiq SearchIQ.This issue affects SearchIQ: from n/a through 4.5.