ghsa

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17.

### Impact Versions [v9.26.0](https://github.com/octokit/webhooks.js/releases/tag/v9.26.0), [v10.9.x](https://github.com/octokit/webhooks.js/releases/tag/v10.9.1)), [v11.1.x](https://github.com/octokit/webhooks.js/releases/tag/v11.1.1), [v12.0.x](https://github.com/octokit/webhooks.js/releases/tag/v12.0.3) all contained the code that would throw the error. Specifically, during a pentest we encountered a bug in the octokit/webhooks library (a dependency of Probot, a framework for building Github Apps). The resulting request was found to cause an uncaught exception that ends the nodejs process. The problem is caused by an issue with error handling in the @octokit/webhooks library because the error can be undefined in some cases. Credit goes to @pb82 (for the early analysis) and @rh-tguittet (for discovery). ### Patches Maintenance releases for the Error being thrown by the verify method in [octokit/webhooks.js](https://github.com/octokit/webhooks.js) * v12 - [v12.0.4](https://githu...

### Impact Anyone who can edit an arbitrary wiki page in an XWiki installation can gain programming right through several cases of missing escaping in the code for displaying sections in the administration interface. This impacts the confidentiality, integrity and availability of the whole XWiki installation. Normally, all users are allowed to edit their own user profile so this should be exploitable by all users of the XWiki instance. The easiest way to reproduce this is to edit any document with the object editor and add an object of type `XWiki.ConfigurableClass` ("Custom configurable sections"). Set "Display in section" and "Display in Category" to "other", set scope to "Wiki and all spaces" and "Heading" to `{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"); println("Hello from Groovy!"){{/groovy}}{{/async}}`. Click "Save". Open `<xwiki-host>/xwiki/bin/view/Main/?sheet=XWiki.AdminSheet&viewer=content&editor=globaladmin&section=othe...

### Impact There is a reflected XSS or also direct remote code execution vulnerability in the code for displaying configurable admin sections. The code that can be passed through a URL parameter is only executed when the user who is visiting the crafted URL has edit right on at least one configuration section. While any user of the wiki could easily create such a section, in this case it is much more convenient to exploit [GHSA-qj86-p74r-7wp5](https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-qj86-p74r-7wp5) which is why this attack scenario won't be further considered in the following. In contrast to GHSA-qj86-p74r-7wp5, this vulnerability doesn't require the attacker to have an account or any access on the wiki. It is sufficient to trick any admin user of the XWiki installation to visit the crafted URL. Alternatively, the URL can also be embedded as image source of an image in any content of the wiki like a comment that could be left by an anonymous user. This vulner...

### Impact The search administration interface doesn't properly escape the id and label of search user interface extensions, allowing the injection of XWiki syntax containing script macros including Groovy macros that allow remote code execution, impacting the confidentiality, integrity and availability of the whole XWiki instance. This attack can be executed by any user who can edit some wiki page like the user's profile (editable by default) as user interface extensions that will be displayed in the search administration can be added on any document by any user. To reproduce, edit any document with the object editor, add an object of type `XWiki.UIExtensionClass`, set "Extension Point Id" to `org.xwiki.platform.search`, set "Extension ID" to `{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from extension id succeeded!"){{/groovy}}{{/async}}`, set "Extension Parameters" to `label={{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from labe...

### Impact The Solr-based search in XWiki discloses the email addresses of users even when obfuscation of email addresses is enabled. To demonstrate the vulnerability, search for `objcontent:email*` using XWiki's regular search interface. ### Patches This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1 by not indexing email address properties when obfuscation is enabled. Further, changing the setting now triggers re-indexing of the affected wiki(s). ### Workarounds We're not aware of any workarounds. ### References * https://jira.xwiki.org/browse/XWIKI-20371 * https://github.com/xwiki/xwiki-platform/commit/3e5272f2ef0dff06a8f4db10afd1949b2f9e6eea ### Attribution This vulnerability was reported on Intigriti by [ynoof](https://twitter.com/ynoofAssiri) @Ynoof5.

### Impact The Solr-based search in XWiki discloses the password hashes of all users to anyone with view right on the respective user profiles. By default, all user profiles are public. To reproduce, it is sufficient to search for `propertyvalue:?* AND reference:*.password` and then deselect the "Document" property under "Result type" in the "Refine your search" widget at the right of the search results. If this displays any passwords or password hashes, the installation is vulnerable. By default, passwords in XWiki are salted and hashed with SHA-512. On XWiki versions affected by [CVE-2022-41933](https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-q2hm-2h45-v5g3), passwords are stored in plain text if they have been set using the password reset feature. This might affect XWiki installations that are using an external authentication mechanism such that passwords aren't stored in the wiki. This vulnerability also affects any configurations used by extensions that contain ...

### Impact In ActiveAdmin versions prior to 2.12.0, a concurrency issue was found that could allow a malicious actor to be able to access potentially private data that belongs to another user. The bug affects the functionality to export data as CSV files, and was caused by a variable holding the collection to be exported being shared across threads and not properly synchronized. The attacker would need access to the same ActiveAdmin application as the victim, and could exploit the issue by timing their request immediately before when they know someone else will request a CSV (e.g. via phishing) or request CSVs frequently and hope someone else makes a concurrent request. ### Patches Versions 2.12.0 and above fixed the problem by completely removing the shared state.

### Summary The value of `nvdApiKey` configuration parameter is logged in clear text in debug mode. ### Details The NVD API key is a kind of secret and should be treated like other secrets when logging in debug mode. Expecting the same behavior as for several password configurations: just print `******` Note that while the NVD API Key is an access token for the NVD API - they are not that sensitive. The only thing an NVD API Token grants is a higher rate limit when making calls to publicly available data. The data available from the NVD API is the same whether you have an API Key or not. ### PoC The nvdApiKey is configured to use an environment variable; when running `mvn -X dependency-check:check` the clear value is logged twice. ### Impact The NVD API key is a kind of secret and should not be exposed. If stolen, an attacker can use this key to obtain already public information. ### UPDATE ### The issue isn't still resoved in 9.0.6: Create a `pom.xml` with the following configur...

### Summary The login page discloses all active user accounts to any unauthenticated browsing request originating on the Local Area Network. ### Details Starting the [Home Assistant 2023.12 release](https://www.home-assistant.io/blog/2023/12/06/release-202312/), the login page returns all currently active user accounts to browsing requests from the Local Area Network. Tests showed that this occurs when: - The request is not authenticated and - The request originated locally, meaning on the Home Assistant host local subnet or any other private subnet (`10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fd00::/8, ::ffff:10.0.0.0/104, ::ffff:172.16.0.0/108, ::ffff:192.168.0.0/112`) The rationale behind this is to make the login more user-friendly (see [release blog post](https://www.home-assistant.io/blog/2023/12/06/release-202312/)) and an experience better aligned with other applications that have multiple user-profiles. However, as a result, all accounts are displayed regardless of them ...