GitLab has remediated an issue in GitLab EE affecting all versions from 18.5 before 18.8.7, 18.9 before 18.9.3, and 18.10 before 18.10.1 that could have allowed an unauthenticated user to access API tokens of self-hosted AI models due to improper access control.

GitLab EE 11.11 and later through 12.7.2 allows Directory Traversal.

GitLab EE 8.0 through 12.7.2 has Incorrect Access Control.

GitLab has remediated an issue in GitLab EE affecting all versions from 19.1 before 19.1.1 that under certain conditions could have allowed a user to access sensitive information that had already been committed to a project, due to insufficient output filtering in Duo Workflows.

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 affecting all versions starting from 12.1. Incorrect headers in specific project page allows attacker to have a temporary read access to the private repository

In GitLab Enterprise Edition (EE) 12.5.0 through 12.7.5, sharing a group with a group could grant project access to unauthorized users.

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.8. Under a special condition it was possible to access data of an internal repository through project fork done by a project member.

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

GitLab EE 8.0 and later through 12.7.2 allows Information Disclosure.

An information disclosure issue in GitLab CE/EE affecting all versions from 16.0 prior to 16.0.6, and version 16.1.0 allows unauthenticated actors to access the import error information if a project was imported from GitHub.

Missing filtering in an error message in GitLab CE/EE affecting all versions prior to 14.7.7, 14.8 prior to 14.8.5, and 14.9 prior to 14.9.2 exposed sensitive information when an include directive fails in the CI/CD configuration.

An issue has been discovered discovered in GitLab EE/CE affecting all versions starting from 15.10 before 17.1.7, all versions starting from 17.2 before 17.2.5, all versions starting from 17.3 before 17.3.2 will disclose user password from repository mirror configuration.

An issue has been discovered in GitLab affecting all versions starting from 12.9 before 16.0.8, all versions starting from 16.1 before 16.1.3, all versions starting from 16.2 before 16.2.2. It was possible to leak a user's email via an error message for groups that restrict membership by email domain.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.5 before 18.4.6, 18.5 before 18.5.4, and 18.6 before 18.6.2 that could have allowed an authenticated user to discover the names of private projects they do not have access through API requests.

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 allows Information Exposure.

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 Path Disclosure. When an error is encountered on project import, the error message will display instance internal information.

An issue was identified in GitLab EE 13.4 or later which leaked internal IP address via error messages.

A verbose error message in GitLab EE affecting all versions since 12.2 could disclose the private email address of a user invited to a group

An issue has been discovered in GitLab affecting all versions starting with 7.1. A member of a private group was able to validate the use of a specific name for private project.

Squid is a caching proxy for the Web. In Squid versions prior to 7.2, a failure to redact HTTP authentication credentials in error handling allows information disclosure. The vulnerability allows a script to bypass browser security protections and learn the credentials a trusted client uses to authenticate. This potentially allows a remote client to identify security tokens or credentials used internally by a web application using Squid for backend load balancing. These attacks do not require Squid to be configured with HTTP authentication. The vulnerability is fixed in version 7.2. As a workaround, disable debug information in administrator mailto links generated by Squid by configuring squid.conf with email_err_data off.

phpMyFAQ is an open source FAQ web application for PHP 8.1+ and MySQL, PostgreSQL and other databases. Prior to 4.0.0, phpMyFAQ exposes the database (ie postgreSQL) server's credential when connection to DB fails. This vulnerability is fixed in 4.0.0.

Generation of Error Message Containing Sensitive Information vulnerability in Hitachi Device Manager on Windows, Linux (Device Manager Agent modules).This issue affects Hitachi Device Manager: before 8.8.5-04.

IBM Db2 for Linux, UNIX and Windows (includes Db2 Connect Server) 11.5 is vulnerable to an insecure cryptographic algorithm and to information disclosure in stack trace under exceptional conditions.

IBM QRadar Suite Software 1.10.12.0 through 1.10.22.0 and IBM Cloud Pak for Security 1.10.0.0 through 1.10.11.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the request. This information could be used in further attacks against the system. IBM X-Force ID: 272201.

Grafana is an open-source platform for monitoring and observability. The Google Sheets data source plugin for Grafana, versions 0.9.0 to 1.2.2 are vulnerable to an information disclosure vulnerability. The plugin did not properly sanitize error messages, making it potentially expose the Google Sheet API-key that is configured for the data source. This vulnerability was fixed in version 1.2.2.

Dispatch is an open source security incident management tool. The server response includes the JWT Secret Key used for signing JWT tokens in error message when the `Dispatch Plugin - Basic Authentication Provider` plugin encounters an error when attempting to decode a JWT token. Any Dispatch users who own their instance and rely on the `Dispatch Plugin - Basic Authentication Provider` plugin for authentication may be impacted, allowing for any account to be taken over within their own instance. This could be done by using the secret to sign attacker crafted JWTs. If you think that you may be impacted, we strongly suggest you to rotate the secret stored in the `DISPATCH_JWT_SECRET` envvar in the `.env` file. This issue has been addressed in commit `b1942a4319` which has been included in the `20230817` release. users are advised to upgrade. There are no known workarounds for this vulnerability.

IBM Cloud Pak System 2.3.3.6, 2.3.36 iFix1, 2.3.3.6 iFix2, 2.3.3.7, 2.3.3.7 iFix1, and 2.3.4.0 could disclose sensitive information about the system that could aid in further attacks against the system.

IBM Cloud Pak System 2.3.3.0, 2.3.3.3, 2.3.3.3 iFix1, 2.3.3.4, 2.3.3.5, 2.3.3.6, 2.3.3.6 iFix1, 2.3.3.6 iFix2, 2.3.3.7, and 2.3.3.7 iFix1 could disclose sensitive information about the system that could aid in further attacks against the system.

IBM Cloud Pak System 2.3.3.0, 2.3.3.3, 2.3.3.3 iFix1, 2.3.3.4, 2.3.3.5, 2.3.3.6, 2.3.3.6 iFix1, 2.3.3.6 iFix2, 2.3.3.7, and 2.3.3.7 iFix1 could disclose sensitive information about the system that could aid in further attacks against the system.

IBM Cloud Pak System displays sensitive information in user messages that could aid in further attacks against the system.

Generation of Error Message Containing Sensitive Information in GitHub repository nocodb/nocodb prior to 0.91.7+.

MISP 2.4.172 mishandles different certificate file extensions in server sync. An attacker can obtain sensitive information because of the nature of the error messages.

IBM Security Verify Information Queue 10.0.4 and 10.0.5 could allow a remote attacker to obtain sensitive information that could aid in further attacks against the system. IBM X-Force ID: 256015.

Generation of Error Message Containing Sensitive Information in Packagist microweber/microweber prior to 1.2.11.

SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions. The `spicedb serve` command contains a flag named `--grpc-preshared-key` which is used to protect the gRPC API from being accessed by unauthorized requests. The values of this flag are to be considered sensitive, secret data. The `/debug/pprof/cmdline` endpoint served by the metrics service (defaulting running on port `9090`) reveals the command-line flags provided for debugging purposes. If a password is set via the `--grpc-preshared-key` then the key is revealed by this endpoint along with any other flags provided to the SpiceDB binary. This issue has been fixed in version 1.19.1. ### Impact All deployments abiding by the recommended best practices for production usage are **NOT affected**: - Authzed's SpiceDB Serverless - Authzed's SpiceDB Dedicated - SpiceDB Operator Users configuring SpiceDB via environment variables are **NOT affected**. Users **MAY be affected** if they expose their metrics port to an untrusted network and are configuring `--grpc-preshared-key` via command-line flag. ### Patches TODO ### Workarounds To workaround this issue you can do one of the following: - Configure the preshared key via an environment variable (e.g. `SPICEDB_GRPC_PRESHARED_KEY=yoursecret spicedb serve`) - Reconfigure the `--metrics-addr` flag to bind to a trusted network (e.g. `--metrics-addr=localhost:9090`) - Disable the metrics service via the flag (e.g. `--metrics-enabled=false`) - Adopt one of the recommended deployment models: [Authzed's managed services](https://authzed.com/pricing) or the [SpiceDB Operator](https://github.com/authzed/spicedb-operator) ### References - [GitHub Security Advisory issued for SpiceDB](https://github.com/authzed/spicedb/security/advisories/GHSA-cjr9-mr35-7xh6) - [Go issue #22085](https://github.com/golang/go/issues/22085) for documenting the risks of exposing pprof to the internet - [Go issue #42834](https://github.com/golang/go/issues/42834) discusses preventing pprof registration to the default serve mux - [semgrep rule go.lang.security.audit.net.pprof.pprof-debug-exposure](https://semgrep.dev/r?q=go.lang.security.audit.net.pprof) checks for a variation of this issue ### Credit We'd like to thank Amit Laish, a security researcher at GE Vernova for responsibly disclosing this vulnerability.

A Sensitive Source Code Path Disclosure vulnerability is found in ElkarBackup v1.3.3. An attacker is able to view the path of the source code jobs/sort where entire source code path is displayed in the browser itself helping the attacker identify the code structure /app/elkarbackup/src/Binovo/ElkarBackupBundle/Controller/DefaultController.php

WWBN AVideo is an open source video platform. In versions up to and including 29.0, plugin/CloneSite/cloneClient.json.php echoes the local CloneSite shared secret ($objClone->myKey, a constant md5($global['systemRootPath'] . $global['salt'])) into the HTTP response body on every unauthenticated request. The unauthenticated error branch was intended to reject non-admin callers without a valid key, but the rejection message interpolates the expected key before die(). When the victim has CloneSite configured with a remote cloneSiteURL (standard federation/backup setup), the leaked myKey is exactly the credential that authenticates the victim to that remote server's cloneServer.json.php, allowing the attacker to impersonate the victim and trigger a full mysqldump of the remote's database to the remote's public videos/clones/ directory Commit e6566f56a28f4556b2a0a09d03717a719dcb49da contains an updated fix.

There is an information disclosure vulnerability in the GoldenDB database product. Attackers can exploit error messages to obtain the system's sensitive information.

Generation of Error Message Containing Sensitive Information vulnerability in the Apache Airflow AWS Provider. This issue affects Apache Airflow AWS Provider versions before 7.2.1.

Server information leak of configuration data when an error is generated in response to a specially crafted message. See Honeywell Security Notification for recommendations on upgrading and versioning.

In SapphireIMS 4097_1, it is possible to guess the registered/active usernames of the software from the errors it gives out for each type of user on the Login form. For "Incorrect User" - it gives an error "The application failed to identify the user. Please contact administrator for help." For "Correct User and Incorrect Password" - it gives an error "Authentication failed. Please login again."

The Journal theme before 3.1.0 for OpenCart allows exposure of sensitive data via SQL errors.

IBM Security Verify Governance Identity Manager 10.0.2 could allow a remote attacker to obtain sensitive information when detailed technical error messages are returned. This information could be used in further attacks against the system.

No exception handling vulnerability which revealed sensitive or excessive information to users.

In Progress® Telerik® UI for AJAX prior to v2026.2.708, RadAsyncUpload client-state processing can distinguish decrypt failures from invalid-JSON parse failures, creating an oracle that reveals protected metadata values to remote attackers.

In Shopware before 6.2.3, the database password is leaked to an unauthenticated user when a DriverException occurs and verbose error handling is enabled.

Play Framework is a web framework for Java and Scala. Verions prior to 2.8.16 are vulnerable to generation of error messages containing sensitive information. Play Framework, when run in dev mode, shows verbose errors for easy debugging, including an exception stack trace. Play does this by configuring its `DefaultHttpErrorHandler` to do so based on the application mode. In its Scala API Play also provides a static object `DefaultHttpErrorHandler` that is configured to always show verbose errors. This is used as a default value in some Play APIs, so it is possible to inadvertently use this version in production. It is also possible to improperly configure the `DefaultHttpErrorHandler` object instance as the injected error handler. Both of these situations could result in verbose errors displaying to users in a production application, which could expose sensitive information from the application. In particular, the constructor for `CORSFilter` and `apply` method for `CORSActionBuilder` use the static object `DefaultHttpErrorHandler` as a default value. This is patched in Play Framework 2.8.16. The `DefaultHttpErrorHandler` object has been changed to use the prod-mode behavior, and `DevHttpErrorHandler` has been introduced for the dev-mode behavior. A workaround is available. When constructing a `CORSFilter` or `CORSActionBuilder`, ensure that a properly-configured error handler is passed. Generally this should be done by using the `HttpErrorHandler` instance provided through dependency injection or through Play's `BuiltInComponents`. Ensure that the application is not using the `DefaultHttpErrorHandler` static object in any code that may be run in production.

IBM Maximo Asset Management 7.6.1.1 and 7.6.1.2 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 210163.