#vulnerability

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

A vulnerability was found in kalcaddle kodbox up to 1.48. It has been rated as critical. Affected by this issue is the function cover of the file plugins/fileThumb/app.php. The manipulation of the argument path leads to server-side request forgery. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 1.48.04 is able to address this issue. The patch is identified as 63a4d5708d210f119c24afd941d01a943e25334c. It is recommended to upgrade the affected component. VDB-248210 is the identifier assigned to this vulnerability.

A vulnerability was found in kalcaddle kodbox up to 1.48. It has been declared as critical. Affected by this vulnerability is the function check of the file plugins/officeViewer/controller/libreOffice/index.class.php. The manipulation of the argument soffice leads to command injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 1.48.04 is able to address this issue. The identifier of the patch is 63a4d5708d210f119c24afd941d01a943e25334c. It is recommended to upgrade the affected component. The identifier VDB-248209 was assigned to this vulnerability.

A vulnerability exists on all versions of Ivanti Connect Secure below 22.6R2 where an attacker can send a specific request which may lead to Denial of Service (DoS) of the appliance.

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

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