Command injection in some Zoom Clients for Windows may allow an authenticated user to conduct a disclosure of information via network access.

Improper input validation in Zoom Desktop Client for Windows, Zoom VDI Client for Windows, and Zoom Meeting SDK for Windows may allow an authenticated user to conduct a disclosure of information via network access.

Business logic error in some Zoom clients may allow an authenticated user to conduct information disclosure via network access.

Improper access control in Zoom Mobile App for iOS and Zoom SDKs for iOS before version 5.16.5 may allow an authenticated user to conduct a disclosure of information via network access.

Cryptographic issues with In-Meeting Chat for some Zoom clients may allow a privileged user to conduct an information disclosure via network access.

Improper input validation in Zoom Desktop Client for Windows before 5.15.5 may allow an authenticated user to enable an information disclosure via network access.

Exposure of resource to wrong sphere in Zoom for Windows and Zoom for MacOS clients before 5.14.10 may allow an authenticated user to potentially enable information disclosure via network access.

Improper input validation in Zoom Desktop Client for Windows, Zoom VDI Client for Windows, and Zoom Meeting SDK for Windows may allow an authenticated user to conduct a disclosure of information via network access.

Client-side enforcement of server-side security in Zoom clients before 5.14.10 may allow an authenticated user to enable information disclosure via network access.

Incorrect ownership assignment in some Zoom Workplace Apps may allow a privileged user to conduct an information disclosure via network access.

Protection mechanism failure for some Zoom Workplace Apps and SDKs may allow an authenticated user to conduct information disclosure via network access.

Zoom On-Premise Meeting Connector MMR before version 4.8.20220815.130 contains an improper access control vulnerability. As a result, a malicious actor could obtain the audio and video feed of a meeting they were not authorized to join and cause other meeting disruptions.

Zooms On-Premise Meeting Connector MMR before version 4.8.113.20220526 fails to properly check the permissions of a Zoom meeting attendee. As a result, a threat actor in the Zooms waiting room can join the meeting without the consent of the host.

Zoom On-Premise Meeting Connector MMR before version 4.8.20220916.131 contains an improper access control vulnerability. As a result, a malicious actor in a meeting or webinar they are authorized to join could prevent participants from receiving audio and video causing meeting disruptions.

A vulnerability in Zoom On-Premise Meeting Connector Controller version 4.8.102.20220310 and On-Premise Meeting Connector MMR version 4.8.102.20220310 exposes process memory fragments to connected clients, which could be observed by a passive attacker.

Insufficient control flow management in some Zoom clients may allow an authenticated user to conduct an information disclosure via network access.

Zoom for Windows clients before version 5.13.3, Zoom Rooms for Windows clients before version 5.13.5 and Zoom VDI for Windows clients before 5.13.1 contain an information disclosure vulnerability. A recent update to the Microsoft Edge WebView2 runtime used by the affected Zoom clients, transmitted text to Microsoft’s online Spellcheck service instead of the local Windows Spellcheck. Updating Zoom remediates this vulnerability by disabling the feature. Updating Microsoft Edge WebView2 Runtime to at least version 109.0.1481.0 and restarting Zoom remediates this vulnerability by updating Microsoft’s telemetry behavior.

Exposure of information intended to be encrypted by some Zoom clients may lead to disclosure of sensitive information.

Sensitive information disclosure in some Zoom Workplace Apps, SDKs, Rooms Clients, and Rooms Controllers may allow a privileged user to conduct an information disclosure via network access.

The Zoom Client for Meetings (for Android, iOS, Linux, macOS, and Windows) before version 5.12.6 is susceptible to a local information exposure vulnerability. A failure to clear data from a local SQL database after a meeting ends and the usage of an insufficiently secure per-device key encrypting that database results in a local malicious user being able to obtain meeting information such as in-meeting chat for the previous meeting attended from that local user account.

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.

Missing authorization checks in the Workspace Module of TYPO3 CMS versions 9.0.0‑9.5.54, 10.0.0‑10.4.53, 11.0.0‑11.5.47, 12.0.0‑12.4.36, and 13.0.0‑13.4.17 allow backend users to directly invoke the corresponding AJAX backend route to disclose sensitive information without having access.

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.

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.

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.

Exposure of Sensitive Information to an Unauthorized Actor in GitHub repository scrapy/scrapy prior to 2.6.1.

Mattermost 6.3.0 and earlier fails to protect email addresses of the creator of the team via one of the APIs, which allows authenticated team members to access this information resulting in sensitive & private information disclosure.

The 2wcom IP-4c 2.15.5 device's web interface includes an information disclosure vulnerability. By sending a crafted POST request to a specific endpoint (/cwi/ajax_request/get_data.php), an authenticated attacker (even with a low-privileged account like guest) can retrieve the hashed passwords for the admin, manager, and guest accounts. This significantly weakens the system's security posture, as these hashes could be cracked offline, granting attackers administrative access to the device.

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.

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.

An issue was discovered in MediaWiki before 1.35.5, 1.36.x before 1.36.3, and 1.37.x before 1.37.1. Some unprivileged users can view confidential information (e.g., IP addresses and User-Agent headers for election traffic) on a testwiki SecurePoll instance.

An exposure of sensitive information to an unauthorized actor vulnerability in Fortinet FortiADC 7.4.0, FortiADC 7.2 all versions, FortiADC 7.1 all versions, FortiADC 7.0 all versions, FortiADC 6.2 all versions may allow an admin with read-only permission to get the external resources password via the logs of the product

The Slider Revolution plugin for WordPress is vulnerable to Sensitive Information Disclosure in versions up to and including 7.0.10. This is due to three compounding design flaws: (1) the plugin leaks a valid backend AJAX nonce (revslider_actions) to all authenticated users including Subscribers via the admin_footer hook; (2) the wordpress.create.image_from_url action is explicitly allowlisted in the $user_allowed array, bypassing the administrator-only access control; (3) the create_wordpress_image_from_url() function accepts an attacker-controlled url parameter that is passed to import_media(), where path_or_url_exists() explicitly accepts local filesystem paths (file_exists() && is_readable()) with no restriction to remote HTTP/HTTPS URLs, and @copy() physically copies those files into the publicly accessible /wp-content/uploads/revslider/ai/ directory. The MIME type check trusts the attacker-supplied content_type parameter to derive the destination extension without verifying actual file content, and the source extension blacklist does not block many sensitive types (.sql, .log, .json, .bak, .xml, .csv, .conf, .yml, .yaml, .pem, .key, .crt, .txt, .db, etc.). This makes it possible for authenticated attackers with Subscriber-level access and above to read the contents of server files with non-blacklisted extensions by having them copied to a publicly accessible URL.

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.

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

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

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.

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.

Sourcegraph is a code search and navigation engine. Sourcegraph prior to version 3.33.2 is vulnerable to a side-channel attack where strings in private source code could be guessed by an authenticated but unauthorized actor. This issue affects the Saved Searches and Code Monitoring features. A successful attack would require an authenticated bad actor to create many Saved Searches or Code Monitors to receive confirmation that a specific string exists. This could allow an attacker to guess formatted tokens in source code, such as API keys. This issue was patched in version 3.33.2 and any future versions of Sourcegraph. We strongly encourage upgrading to secure versions. If you are unable to, you may disable Saved Searches and Code Monitors.

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.

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.

The affected product is vulnerable to a disclosure of peer username and password by allowing all users access to read global variables.

The Pi-hole is a DNS sinkhole that protects your devices from unwanted content without installing any client-side software. A vulnerability has been discovered in Pihole that allows an authenticated user on the platform to read internal server files arbitrarily, and because the application runs from behind, reading files is done as a privileged user.If the URL that is in the list of "Adslists" begins with "file*" it is understood that it is updating from a local file, on the other hand if it does not begin with "file*" depending on the state of the response it does one thing or another. The problem resides in the update through local files. When updating from a file which contains non-domain lines, 5 of the non-domain lines are printed on the screen, so if you provide it with any file on the server which contains non-domain lines it will print them on the screen. This vulnerability is fixed by 5.18.

your_spotify is an open source, self hosted Spotify tracking dashboard. YourSpotify version <1.8.0 allows users to create a public token in the settings, which can be used to provide guest-level access to the information of that specific user in YourSpotify. The /me API endpoint discloses Spotify API access and refresh tokens to guest users. Attackers with access to a public token for guest access to YourSpotify can therefore obtain access to Spotify API tokens of YourSpotify users. As a consequence, attackers may extract profile information, information about listening habits, playlists and other information from the corresponding Spotify profile. In addition, the attacker can pause and resume playback in the Spotify app at will. This issue has been resolved in version 1.8.0. Users are advised to upgrade. There are no known workarounds for this issue.

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.

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