Icinga DB Web provides a graphical interface for Icinga monitoring. Before 1.1.4 and 1.2.3, an authorized user with access to Icinga DB Web, can use a custom variable in a filter that is either protected by icingadb/protect/variables or hidden by icingadb/denylist/variables, to guess values assigned to it. Versions 1.1.4 and 1.2.3 respond with an error if such a custom variable is used.

Icinga Web 2 is an open source monitoring web interface, framework, and command-line interface. A vulnerability in which custom variables are exposed to unauthorized users exists between versions 2.0.0 and 2.8.2. Custom variables are user-defined keys and values on configuration objects in Icinga 2. These are commonly used to reference secrets in other configurations such as check commands to be able to authenticate with a service being checked. Icinga Web 2 displays these custom variables to logged in users with access to said hosts or services. In order to protect the secrets from being visible to anyone, it's possible to setup protection rules and blacklists in a user's role. Protection rules result in `***` being shown instead of the original value, the key will remain. Backlists will hide a custom variable entirely from the user. Besides using the UI, custom variables can also be accessed differently by using an undocumented URL parameter. By adding a parameter to the affected routes, Icinga Web 2 will show these columns additionally in the respective list. This parameter is also respected when exporting to JSON or CSV. Protection rules and blacklists however have no effect in this case. Custom variables are shown as-is in the result. The issue has been fixed in the 2.9.0, 2.8.3, and 2.7.5 releases. As a workaround, one may set up a restriction to hide hosts and services with the custom variable in question.

Icinga DB Web provides a graphical interface for Icinga monitoring. Starting in version 1.2.0 and prior to version 1.2.2, users with access to Icinga Dependency Views, are allowed to see hosts and services that they weren't meant to on the dependency map. However, the name of an object will not be revealed nor does this grant access to a host's or service's detail view. Please note that this only affects the restrictions `filter/hosts` and `filter/services`. `filter/objects` is not affected by this and restricts objects as it is supposed to. Version 1.2.2 applies these restrictions properly. As a workaround, one may downgrade to version 1.1.3.

Icinga Director is an Icinga config deployment tool. A Security vulnerability has been found starting in version 1.0.0 and prior to 1.10.4 and 1.11.4 on several director endpoints of REST API. To reproduce this vulnerability an authenticated user with permission to access the Director is required (plus api access with regard to the api endpoints). And even though some of these Icinga Director users are restricted from accessing certain objects, are able to retrieve information related to them if their name is known. This makes it possible to change the configuration of these objects by those Icinga Director users restricted from accessing them. This results in further exploitation, data breaches and sensitive information disclosure. Affected endpoints include icingaweb2/director/service, if the host name is left out of the query; icingaweb2/directore/notification; icingaweb2/director/serviceset; and icingaweb2/director/scheduled-downtime. In addition, the endpoint `icingaweb2/director/services?host=filteredHostName` returns a status code 200 even though the services for the host is filtered. This in turn lets the restricted user know that the host `filteredHostName` exists even though the user is restricted from accessing it. This could again result in further exploitation of this information and data breaches. Icinga Director has patches in versions 1.10.4 and 1.11.4. If upgrading is not feasible, disable the director module for the users other than admin role for the time being.

Moodle exposed the names of hidden groups to users who had permission to create calendar events but not to view hidden groups. This could reveal private or restricted group information.

An exposure of sensitive information to an unauthorized actor vulnerability [CWE-200] in Fortinet FortiADC version 7.4.0, version 7.2.3 and below, version 7.1.4 and below, 7.0 all versions, 6.2 all versions may allow an authenticated attacker to obtain sensitive data via crafted HTTP or HTTPs requests.

Autel MaxiCharger AC Wallbox Commercial Serial Number Exposed Dangerous Method Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Autel MaxiCharger AC Wallbox Commercial EV chargers. Authentication is required to exploit this vulnerability. The specific flaw exists within the implementation of the Autel Technician API. The issue results from an exposed dangerous method. An attacker can leverage this vulnerability to disclose credentials, leading to further compromise. Was ZDI-CAN-26351.

When an error occurs in the application a full stacktrace is provided to the user. The stacktrace lists class and method names as well as other internal information. An attacker thus receives information about the technology used and the structure of the application.

PostgreSQL Anonymizer v2.0 and v2.1 contain a vulnerability that allows a masked user to bypass the masking rules defined on a table and read the original data using a database cursor or the --insert option of pg_dump. This problem occurs only when dynamic masking is enabled, which is not the default setting. The problem is resolved in version 2.2.1

Zoho ManageEngine Desktop Central before 10.0.662 allows authenticated users to obtain sensitive information from the database by visiting the Reports page.

An issue was discovered in AXIS BANK LIMITED Axis Mobile App 9.9 that allows attackers to obtain sensitive information without a UPI PIN, such as account information, balances, transaction history, and unspecified other information. NOTE: the Supplier's perspective is that this is an intended feature and "does not reveal much sensitive information."

The Doneren met Mollie plugin for WordPress is vulnerable to Sensitive Data Exposure in versions up to, and including, 2.8.5 via the dmm_export_donations() function which is called via the admin_post_dmm_export hook due to missing capability checks. This can allow authenticated attackers to extract a CSV file that contains sensitive information about the donors.

In the TransformXML processor of Apache NiFi before 1.15.1 an authenticated user could configure an XSLT file which, if it included malicious external entity calls, may reveal sensitive information.

Insufficient user input filtering leads to arbitrary file read by non-authenticated attacker, which results in sensitive information disclosure.

Scrapy is a high-level web crawling and scraping framework for Python. If you use `HttpAuthMiddleware` (i.e. the `http_user` and `http_pass` spider attributes) for HTTP authentication, all requests will expose your credentials to the request target. This includes requests generated by Scrapy components, such as `robots.txt` requests sent by Scrapy when the `ROBOTSTXT_OBEY` setting is set to `True`, or as requests reached through redirects. Upgrade to Scrapy 2.5.1 and use the new `http_auth_domain` spider attribute to control which domains are allowed to receive the configured HTTP authentication credentials. If you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.5.1 is not an option, you may upgrade to Scrapy 1.8.1 instead. If you cannot upgrade, set your HTTP authentication credentials on a per-request basis, using for example the `w3lib.http.basic_auth_header` function to convert your credentials into a value that you can assign to the `Authorization` header of your request, instead of defining your credentials globally using `HttpAuthMiddleware`.

A flaw was found in postgresql. Using an UPDATE ... RETURNING command on a purpose-crafted table, an authenticated database user could read arbitrary bytes of server memory. The highest threat from this vulnerability is to data confidentiality.

Apache Guacamole 1.3.0 and older may incorrectly include a private tunnel identifier in the non-private details of some REST responses. This may allow an authenticated user who already has permission to access a particular connection to read from or interact with another user's active use of that same connection.

A credential leak vulnerability was found in Red Hat Satellite. This flaw exposes the compute resources credentials through VMs that are running on these resources in Satellite.

GitProxy is an application that stands between developers and a Git remote endpoint. In versions 1.19.1 and below, attackers can inject extra commits into the pack sent to GitHub, commits that aren’t pointed to by any branch. Although these “hidden” commits never show up in the repository’s visible history, GitHub still serves them at their direct commit URLs. This lets an attacker exfiltrate sensitive data without ever leaving a trace in the branch view. We rate this a High‑impact vulnerability because it completely compromises repository confidentiality. This is fixed in version 1.19.2.

An exposure of sensitive information to an unauthorized actor vulnerability in Fortinet FortiSandbox 4.4.0 through 4.4.4, FortiSandbox 4.2.1 through 4.2.6, FortiSandbox 4.0 all versions, FortiSandbox 3.2.2 through 3.2.4, FortiSandbox 3.1.5 allows attacker to information disclosure via HTTP get requests.

Endress+Hauser Ecograph T (Neutral/Private Label) (RSG35, ORSG35) and Memograph M (Neutral/Private Label) (RSG45, ORSG45) with Firmware version V2.0.0 and above is prone to exposure of sensitive information to an unauthorized actor. The firmware release has a dynamic token for each request submitted to the server, which makes repeating requests and analysis complex enough. Nevertheless, it's possible and during the analysis it was discovered that it also has an issue with the access-control matrix on the server-side. It was found that a user with low rights can get information from endpoints that should not be available to this user.

Opencast is a free, open-source platform to support the management of educational audio and video content. Prior to version 17.6, Opencast would incorrectly send the hashed global system account credentials (ie: org.opencastproject.security.digest.user and org.opencastproject.security.digest.pass) when attempting to fetch mediapackage elements included in a mediapackage XML file. A previous CVE prevented many cases where the credentials were inappropriately sent, but not all. Anyone with ingest permissions could cause Opencast to send its hashed global system account credentials to a url of their choosing. This issue is fixed in Opencast 17.6.

OpenEMR is a free and open source electronic health records and medical practice management application. Versions prior to 7.0.4 have a vulnerability where sensitive data is unintentionally revealed to unauthorized parties. Contents of Clinical Notes and Care Plan, where an encounter has Sensitivity=high, can be viewed and changed by users who do not have Sensitivities=high privilege. Version 7.0.4 fixes the issue.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wholesale Team WholesaleX.This issue affects WholesaleX: from n/a through 1.3.1.

CreateWiki is Miraheze's MediaWiki extension for requesting & creating wikis. An oversight during the writing of the patch for CVE-2024-29897 may have exposed suppressed wiki requests to private wikis that added Special:RequestWikiQueue to the read whitelist to users without the `(read)` permission. This vulnerability is fixed in 8f8442ed5299510ea3e58416004b9334134c149c.

Exposure of sensitive information to an unauthorized actor in Azure Virtual Machines allows an authorized attacker to disclose information over a network.

Vela is a Pipeline Automation (CI/CD) framework built on Linux container technology written in Golang. Vela pipelines can use variable substitution combined with insensitive fields like `parameters`, `image` and `entrypoint` to inject secrets into a plugin/image and — by using common substitution string manipulation — can bypass log masking and expose secrets without the use of the commands block. This unexpected behavior primarily impacts secrets restricted by the "no commands" option. This can lead to unintended use of the secret value, and increased risk of exposing the secret during image execution bypassing log masking. **To exploit this** the pipeline author must be supplying the secrets to a plugin that is designed in such a way that will print those parameters in logs. Plugin parameters are not designed for sensitive values and are often intentionally printed throughout execution for informational/debugging purposes. Parameters should therefore be treated as insensitive. While Vela provides secrets masking, secrets exposure is not entirely solved by the masking process. A docker image (plugin) can easily expose secrets if they are not handled properly, or altered in some way. There is a responsibility on the end-user to understand how values injected into a plugin are used. This is a risk that exists for many CICD systems (like GitHub Actions) that handle sensitive runtime variables. Rather, the greater risk is that users who restrict a secret to the "no commands" option and use image restriction can still have their secret value exposed via substitution tinkering, which turns the image and command restrictions into a false sense of security. This issue has been addressed in version 0.23.2. Users are advised to upgrade. Users unable to upgrade should not provide sensitive values to plugins that can potentially expose them, especially in `parameters` that are not intended to be used for sensitive values, ensure plugins (especially those that utilize shared secrets) follow best practices to avoid logging parameters that are expected to be sensitive, minimize secrets with `pull_request` events enabled, as this allows users to change pipeline configurations and pull in secrets to steps not typically part of the CI process, make use of the build approval setting, restricting builds from untrusted users, and limit use of shared secrets, as they are less restrictive to access by nature.

Contao is an open source content management system. Starting in version 4.9.0 and prior to versions 4.13.40 and 5.3.4, when checking for broken links on protected pages, Contao sends the cookie header to external urls as well, the passed options for the http client are used for all requests. Contao versions 4.13.40 and 5.3.4 have a patch for this issue. As a workaround, disable crawling protected pages.

In Nagios Log Server versions prior to 2024R2.0.3, when a user's configured default dashboard is deleted, the application does not reliably fall back to an empty, default dashboard. In some implementations this can result in an unexpected dashboard being presented as the user's default view. Depending on the product's dashboard sharing and access policies, this behavior may cause information exposure or unexpected privilege exposure.

An issue was discovered in Mattermost Server before 3.0.0. It potentially allows attackers to obtain sensitive information (credential fields within config.json) via the System Console UI.

The /log endpoint on a Juju controller lacked sufficient authorization checks, allowing unauthorized users to access debug messages that could contain sensitive information.

Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. Starting in version 2.2 and prior to version 3.3.7, an endpoint used to display details of users listed in certain fields (such as ACLs) could be misused to dump basic user details (such as name, affiliation and email) in bulk. Version 3.3.7 fixes the issue. Owners of instances that allow everyone to create a user account, who wish to truly restrict access to these user details, should consider restricting user search to managers. As a workaround, it is possible to restrict access to the affected endpoints (e.g. in the webserver config), but doing so would break certain form fields which could no longer show the details of the users listed in those fields, so upgrading instead is highly recommended.

In Rundeck before version 3.2.6, authenticated users can craft a request that reveals Execution data and logs and Job details that they are not authorized to see. Depending on the configuration and the way that Rundeck is used, this could result in anything between a high severity risk, or a very low risk. If access is tightly restricted and all users on the system have access to all projects, this is not really much of an issue. If access is wider and allows login for users that do not have access to any projects, or project access is restricted, there is a larger issue. If access is meant to be restricted and secrets, sensitive data, or intellectual property are exposed in Rundeck execution output and job data, the risk becomes much higher. This vulnerability is patched in version 3.2.6

Tuleap is an open source suite to improve management of software developments and collaboration. Prior to version 15.5.99.76 of Tuleap Community Edition and prior to versions 15.5-4 and 15.4-7 of Tuleap Enterprise Edition, users with a read access to a tracker where the mass update feature is used might get access to restricted information. Tuleap Community Edition 15.5.99.76, Tuleap Enterprise Edition 15.5-4, and Tuleap Enterprise Edition 15.4-7 contain a patch for this issue.

PagerDuty Runbook through 2025-06-12 exposes stored secrets directly in the webpage DOM at the configuration page. Although these secrets appear masked as password fields, the actual secret values are present in the page source and can be revealed by simply modifying the input field type from "password" to "text" using browser developer tools. This vulnerability is exploitable by administrative users who have access to the configuration page.

Lemmy is a link aggregator and forum for the fediverse. Starting in version 0.17.0 and prior to version 0.19.1, users can report private messages, even when they're neither sender nor recipient of the message. The API response to creating a private message report contains the private message itself, which means any user can just iterate over message ids to (loudly) obtain all private messages of an instance. A user with instance admin privileges can also abuse this if the private message is removed from the response, as they're able to see the resulting reports. Creating a private message report by POSTing to `/api/v3/private_message/report` does not validate whether the reporter is the recipient of the message. lemmy-ui does not allow the sender to report the message; the API method should likely be restricted to accessible to recipients only. The API response when creating a report contains the `private_message_report_view` with all the details of the report, including the private message that has been reported: Any authenticated user can obtain arbitrary (untargeted) private message contents. Privileges required depend on the instance configuration; when registrations are enabled without application system, the privileges required are practically none. When registration applications are required, privileges required could be considered low, but this assessment heavily varies by instance. Version 0.19.1 contains a patch for this issue. A workaround is available. If an update to a fixed Lemmy version is not immediately possible, the API route can be blocked in the reverse proxy. This will prevent anyone from reporting private messages, but it will also prevent exploitation before the update has been applied.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Elementor Pro.This issue affects Elementor Pro: from n/a through 3.19.2.

Mattermost fails to properly authorize the requests fetching team associated AD/LDAP groups, allowing a user to fetch details of AD/LDAP groups of a team that they are not a member of. 

Percona XtraBackup before 2.4.20 unintentionally writes the command line to any resulting backup file output. This may include sensitive arguments passed at run time. In addition, when --history is passed at run time, this command line is also written to the PERCONA_SCHEMA.xtrabackup_history table.

The created backup files are unencrypted, making the application vulnerable for gathering sensitive information by downloading and decompressing the backup files.

A flaw was found in postgresql. A purpose-crafted query can read arbitrary bytes of server memory. In the default configuration, any authenticated database user can complete this attack at will. The attack does not require the ability to create objects. If server settings include max_worker_processes=0, the known versions of this attack are infeasible. However, undiscovered variants of the attack may be independent of that setting.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, when credentials are fetched with a credentialName filter parameter, the encryptedData field is not stripped from the response. The code properly omits encryptedData when no filter is used but fails to do so when a filter is used. This issue has been patched in version 3.1.2.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Cozmoslabs Profile Builder Pro.This issue affects Profile Builder Pro: from n/a through 3.10.0.

A flaw has been found in Kilo-Org kilocode up to 7.0.47. This issue affects the function Load of the file packages/opencode/src/config/config.ts of the component Environment Variable Handler. Executing a manipulation of the argument KILO_CONFIG_CONTENT can lead to information disclosure. It is possible to launch the attack remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Concurrent execution using shared resource with improper synchronization ('race condition') in SQL Server allows an authorized attacker to disclose information over a network.

Exposure of sensitive information to an unauthorized actor in Microsoft Graph allows an authorized attacker to disclose information over a network.

The WP Register Profile With Shortcode plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 3.6.2 via the 'rp_user_data' shortcode. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract sensitive data from user meta like hashed passwords, usernames, and more.

IBM Guardium Data Protection 12.2.1, and 12.2.2 's add-on feature of Guardium Data Protection named "Long Term Retention" (LTR) can expose sensitive credentials in debug mode.

Exposure of Sensitive Information to an Unauthorized Actor, Exposure of private personal information to an unauthorized actor vulnerability in MeWare Software Development Inc. PDKS allows Excavation. This issue affects PDKS: from V16.20200313 before VMYR_3.5.2025117.

In ZOHO Password Manager Pro (PMP) 8.3.0 (Build 8303) and 8.4.0 (Build 8400,8401,8402), underprivileged users can obtain sensitive information (entry password history) via a vulnerable hidden service.