XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions it's possible to guess if a user has an account on the wiki by using the "Forgot your password" form, even if the wiki is closed to guest users. This problem has been patched on XWiki 12.10.9, 13.4.1 and 13.6RC1. Users are advised yo update. There are no known workarounds for this issue.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. The office document viewer macro was allowing anyone to see any file content from the hosting server, provided that the office server was connected and depending on the permissions of the user running the servlet engine (e.g. tomcat) running XWiki. The same vulnerability also allowed to perform internal requests to resources from the hosting server. The problem has been patched in XWiki 13.10.11, 14.10.1, 14.4.8, 15.0-rc-1. Users are advised to upgrade. It might be possible to workaround this vulnerability by running XWiki in a sandbox with a user with very low privileges on the machine.

XWiki Confluence Migrator Pro helps admins to import confluence packages into their XWiki instance. The homepage of the application is public which enables a guest to download the package which might contain sensitive information. This vulnerability is fixed in 1.11.7.

XWiki Platform is a generic wiki platform. Starting in 7.2-milestone-2 and prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, 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. This vulnerability also affects any configurations used by extensions that contain passwords like API keys that are viewable for the attacker. Normally, such passwords aren't accessible but this vulnerability would disclose them as plain text. This has been patched in XWiki 14.10.15, 15.5.2 and 15.7RC1. There are no known workarounds for this vulnerability.

macro-pdfviewer is a PDF Viewer Macro for XWiki using Mozilla pdf.js. The PDF Viewer macro allows an attacker to view any attachment using the "Delegate my view right" feature as long as the attacker can view a page whose last author has access to the attachment. For this, the attacker only needs to provide the reference to a PDF file to the macro. To obtain the reference of the desired attachment, the attacker can access the Page Index, Attachments tab. Even if the UI shows N/A, the user can inspect the page and check the HTTP request that fetches the live data entries. The attachment URL is available in the returned JSON for all attachments, including protected ones and allows getting the necessary values. This vulnerability is fixed in version 2.5.6.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. The `modifications` rest endpoint does not filter out entries according to the user's rights. Therefore, information hidden from unauthorized users are exposed though the `modifications` rest endpoint (comments and page names etc). Users should upgrade to XWiki 14.6+, 14.4.3+, or 13.10.8+. Older versions have not been patched. There are no known workarounds.

XWiki OIDC has various tools to manipulate OpenID Connect protocol in XWiki. Prior to version 1.29.1, even if a wiki has an OpenID provider configured through its xwiki.properties, it is possible to provide a third party provider its details through request parameters. One can then bypass the XWiki authentication altogether by specifying its own provider through the oidc.endpoint.* request parameters (or by using an XWiki-based OpenID provider with oidc.xwikiprovider. With the same approach, one could also provide a specific group mapping through oidc.groups.mapping that would make his user automatically part of the XWikiAdminGroup. This issue has been patched, please upgrade to 1.29.1. There is no workaround, an upgrade of the authenticator is required.

XWiki Platform Web Templates are templates for XWiki Platform, a generic wiki platform. Through the suggestion feature, string and list properties of objects the user shouldn't have access to can be accessed in versions prior to 13.10.4 and 14.2. This includes private personal information like email addresses and salted password hashes of registered users but also other information stored in properties of objects. Sensitive configuration fields like passwords for LDAP or SMTP servers could be accessed. By exploiting an additional vulnerability, this issue can even be exploited on private wikis at least for string properties. The issue is patched in version 13.10.4 and 14.2. Password properties are no longer displayed and rights are checked for other properties. A workaround is available. The template file `suggest.vm` can be replaced by a patched version without upgrading or restarting XWiki unless it has been overridden, in which case the overridden template should be patched, too. This might need adjustments for older versions, though.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In versions from 14.4.2 to before 16.4.8, 16.5.0-rc-1 to before 16.10.7, and 17.0.0-rc-1 to before 17.4.0-rc-1, the PDF export jobs store sensitive cookies unencrypted in job statuses. XWiki shouldn't store passwords in plain text, and it shouldn't be possible to gain access to plain text passwords by gaining access to, e.g., a backup of the data directory. This vulnerability has been patched in XWiki 16.4.8, 16.10.7, and 17.4.0-rc-1.

XWiki is an open-source wiki software platform. From 16.7.0 to 16.10.11, 17.4.4, or 17.7.0, in an instance which is using the XWiki Jetty package (XJetty), a context is exposed to statically access any file located in the webapp/ folder. It allows accessing files which might contains credentials. Fixed in 16.10.11, 17.4.4, and 17.7.0.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In versions 4.2-milestone-2 through 16.10.6, configuration files are accessible through jsx and sx endpoints. It's possible to access and read configuration files by using URLs such as `http://localhost:8080/bin/ssx/Main/WebHome?resource=../../WEB-INF/xwiki.cfg&minify=false`. This is fixed in version 16.10.7.

XWiki is a generic wiki platform. In XWiki Platform versions 10.9 through 16.4.6, 16.5.0-rc-1 through 16.10.2, and 17.0.0-rc-1, the title of every single page whose reference is known can be accessed through the REST API as long as an XClass with a page property is accessible, this is the default for an XWiki installation. This allows an attacker to get titles of pages whose reference is known, one title per request. This doesn't affect fully private wikis as the REST endpoint checks access rights on the XClass definition. The impact on confidentiality depends on the strategy for page names. By default, page names match the title, so the impact should be low but if page names are intentionally obfuscated because the titles are sensitive, the impact could be high. This has been fixed in XWiki 16.4.7, 16.10.3 and 17.0.0 by adding access control checks before getting the title of any page.

XWiki Platform is a generic wiki platform. Starting in version 7.3-milestone-1 and prior to versions 14.4.8, 14.10.6, and 15.1, ny user can call a REST endpoint and obtain the obfuscated passwords, even when the mail obfuscation is activated. The issue has been patched in XWiki 14.4.8, 14.10.6, and 15.1. There is no known workaround.

XWiki Platform is a generic wiki platform. Starting in version 3.5-milestone-1 and prior to versions 14.4.8, 14.10.4, and 15.0-rc-1, the mail obfuscation configuration was not fully taken into account. While the mail displayed to the end user was obfuscated, the rest response was also containing the mail unobfuscated and users were able to filter and sort on the unobfuscated, allowing them to infer the mail content. The consequence was the possibility to retrieve the email addresses of all users even when obfuscated. This has been patched in XWiki 14.4.8, 14.10.4, and 15.0-rc-1.

XWiki Commons are technical libraries common to several other top level XWiki projects. Rights added to a document are not taken into account for viewing it once it's deleted. Note that this vulnerability only impact deleted documents that where containing view rights: the view rights provided on a space of a deleted document are properly checked. The problem has been patched in XWiki 14.10 by checking the rights of current user: only admin and deleter of the document are allowed to view it.

XWiki Platform is a generic wiki platform. Prior to 15.10.14, 16.4.6, and 16.10.0-rc-1, it's possible for an user to get access to private information through the REST API - but could also be through another API - when a sub wiki is using "Prevent unregistered users to view pages". The vulnerability only affects subwikis, and it only concerns specific right options such as "Prevent unregistered users to view pages". or "Prevent unregistered users to edit pages". It's possible to detect the vulnerability by enabling "Prevent unregistered users to view pages" and then trying to access a page through the REST API without using any credentials. The vulnerability has been patched in XWiki 15.10.14, 16.4.6 and 16.10.0RC1.

macro-pdfviewer is a PDF Viewer Macro for XWiki using Mozilla pdf.js. Any user with view right on XWiki.PDFViewerService can access any attachment stored in the wiki as the "key" that is passed to prevent this is computed incorrectly, calling skip on the digest stream doesn't update the digest. This is fixed in 2.5.6.

XWiki Platform is a generic wiki platform. Starting in version 6.3-milestone-2 and prior to versions 14.10.15, 15.5.1, and 15.6RC1, the Solr-based search suggestion provider that also duplicates as generic JavaScript API for search results in XWiki exposes the content of all documents of all wikis to anybody who has access to it, by default it is public. This exposes all information stored in the wiki (but not some protected information like password hashes). While there is a right check normally, the right check can be circumvented by explicitly requesting fields from Solr that don't include the data for the right check. This has been fixed in XWiki 15.6RC1, 15.5.1 and 14.10.15 by not listing documents whose rights cannot be checked. No known workarounds are available.

XWiki Platform before 12.8 mishandles escaping in the property displayer.

XWiki Platform Old Core is a core package for XWiki Platform, a generic wiki platform. Prior to versions 14.2 and 13.10.4, all rights checks that would normally prevent a user from viewing a document on a wiki can be bypassed using the login action and directly specified templates. This exposes title, content and comments of any document and properties of objects, though class and property name must be known. This is also exploitable on private wikis. This has been patched in versions 14.2 and 13.10.4 by properly checking view rights before loading documents and disallowing non-default templates in the login, registration and skin action. As a workaround, it would be possible to protect all templates individually by adding code to check access rights first.

### Impact It's possible to know if a user has or not an account in a wiki related to an email address, and which username(s) is actually tied to that email by forging a request to the Forgot username page. Note that since this page does not have a CSRF check it's quite easy to perform a lot of those requests. ### Patches This issue has been patched in XWiki 12.10.5 and 13.2RC1. Two different patches are provided: - a first one to fix the CSRF problem - a more complex one that now relies on sending an email for the Forgot username process. ### Workarounds It's possible to fix the problem without uprading by editing the ForgotUsername page in version below 13.x, to use the following code: https://github.com/xwiki/xwiki-platform/blob/69548c0320cbd772540cf4668743e69f879812cf/xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-ui/src/main/resources/XWiki/ForgotUsername.xml#L39-L123 In version after 13.x it's also possible to edit manually the forgotusername.vm file, but it's really encouraged to upgrade the version here. ### References * https://jira.xwiki.org/browse/XWIKI-18384 * https://jira.xwiki.org/browse/XWIKI-18408 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki](https://jira.xwiki.org) * Email us at [security ML](mailto:security@xwiki.org)

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Between (and including) versions 13.1RC1 and 13.1, the reset password form reveals the email address of users just by giving their username. The problem has been patched on XWiki 13.2RC1. As a workaround, it is possible to manually modify the `resetpasswordinline.vm` to perform the changes made to mitigate the vulnerability.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Users without the right to view documents can deduce their existence by repeated Livetable queries. The issue has been patched in XWiki 14.6RC1, 13.10.8, and 14.4.3, the response is not properly cleaned up of obfuscated entries. As a workaround, The patch for the document `XWiki.LiveTableResultsMacros` can be manually applied or a XAR archive of a patched version can be imported, on versions 12.10.11, 13.9-rc-1, and 13.4.4. There are no known workarounds for this issue.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Starting in version 5.0-milestone-1 and prior to versions 14.4.8, 14.10.4, and 15.0-rc-1, tags from pages not viewable to the current user are leaked by the tags API. This information can also be exploited to infer the document reference of non-viewable pages. This vulnerability has been patched in XWiki 14.4.8, 14.10.4, and 15.0-rc-1.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. It's possible to get access to notification filters of any user by using a URL such as `<hostname>xwiki/bin/get/XWiki/Notifications/Code/NotificationFilterPreferenceLivetableResults?outputSyntax=plain&type=custom&user=<username>`. This vulnerability impacts all versions of XWiki since 13.2-rc-1. The filters do not provide much information (they mainly contain references which are public data in XWiki), though some info could be used in combination with other vulnerabilities. This vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0RC1. The patch consists in checking the rights of the user when sending the data. Users are advised to upgrade. It's possible to workaround the vulnerability by applying manually the patch: it's possible for an administrator to edit directly the document `XWiki.Notifications.Code.NotificationFilterPreferenceLivetableResults` to apply the same changes as in the patch. See commit c8c6545f9bde6f5aade994aa5b5903a67b5c2582.

XWiki Platform is a generic wiki platform. Prior to versions 14.10.15, 15.5.2, and 15.7-rc-1, 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. 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. There are no known workarounds for this vulnerability.

XWiki Platform is a generic wiki platform. Starting in version 5.0-rc-1 and prior to versions 14.10.19, 15.5.4, and 15.9-rc-1, it is possible to access the hash of a password by using the diff feature of the history whenever the object storing the password is deleted. Using that vulnerability it's possible for an attacker to have access to the hash password of a user if they have rights to edit the users' page. With the default right scheme in XWiki this vulnerability is normally prevented on user profiles, except by users with Admin rights. Note that this vulnerability also impacts any extensions that might use passwords stored in xobjects: for those usecases it depends on the right of those pages. There is currently no way to be 100% sure that this vulnerability has been exploited, as an attacker with enough privilege could have deleted the revision where the xobject was deleted after rolling-back the deletion. But again, this operation requires high privileges on the target page (Admin right). A page with a user password xobject which have in its history a revision where the object has been deleted should be considered at risk and the password should be changed there. a diff, to ensure it's not coming from a password field. As another mitigation, admins should ensure that the user pages are properly protected: the edit right shouldn't be allowed for other users than Admin and owner of the profile (which is the default right). There is not much workaround possible for a privileged user other than upgrading XWiki.

XWiki Full Calendar Macro displays objects from the wiki on the calendar. Prior to version 2.4.6, users with the rights to view the Calendar.JSONService page (including guest users) can exploit the data leak vulnerability by accessing database info, with the exception of passwords. This issue has been patched in version 2.4.6.

Import functionality is vulnerable to DNS rebinding attacks between verification and processing of the URL.  Project administrators can run these imports, which could cause Allura to read from internal services and expose them. This issue affects Apache Allura from 1.0.1 through 1.16.0. Users are recommended to upgrade to version 1.17.0, which fixes the issue. If you are unable to upgrade, set "disable_entry_points.allura.importers = forge-tracker, forge-discussion" in your .ini config file.

A vulnerability was identified in h2oai h2o-3 up to 7402. Affected by this issue is the function importFiles of the file h2o-core/src/main/java/water/persist/PersistNFS.java of the component ImportFile API. Such manipulation leads to information disclosure. The attack can be executed remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

Shopware is an open source eCommerce platform. Versions prior to 6.3.5.1 may leak of information via Store-API. The vulnerability could only be fixed by changing the API system, which involves a non-backward-compatible change. Only consumers of the Store-API should be affected by this change. We recommend to update to the current version 6.3.5.1. You can get the update to 6.3.5.1 regularly via the Auto-Updater or directly via the download overview. https://www.shopware.com/en/download/#shopware-6 The vulnerability could only be fixed by changing the API system, which involves a non-backward-compatible change. Only consumers of the Store-API should be affected by this change. Please check your plugins if you have it in use. Detailed technical information can be found in the upgrade information. https://github.com/shopware/platform/blob/v6.3.5.1/UPGRADE-6.3.md#6351 ### Workarounds For older versions of 6.1 and 6.2, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version. https://store.shopware.com/en/detail/index/sArticle/518463/number/Swag136939272659 ### For more information https://docs.shopware.com/en/shopware-6-en/security-updates/security-update-02-2021

Information disclosure in the DOM: Security component. This vulnerability was fixed in Firefox 151 and Thunderbird 151.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Exeebit phpinfo() WP.This issue affects phpinfo() WP: from n/a through 5.0.

Information disclosure in the IP Protection component. This vulnerability was fixed in Firefox 151 and Thunderbird 151.

In the module "Axepta" (axepta) before 1.3.4 from Quadra Informatique for PrestaShop, a guest can download partial credit card information (expiry date) / postal address / email / etc. without restriction due to a lack of permissions control.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Scribit GDPR Compliance.This issue affects GDPR Compliance: from n/a through 1.2.5.

A flaw exists in tang, a network-based cryptographic binding server, which could result in leak of private keys.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Ninja Team Filebird.This issue affects Filebird: from n/a through 5.6.3.

Nedis SmartLife android app v1.4.0 was discovered to contain an API key disclosure vulnerability.

The Jupyter Server provides the backend for Jupyter web applications. Jupyter Server on Windows has a vulnerability that lets unauthenticated attackers leak the NTLMv2 password hash of the Windows user running the Jupyter server. An attacker can crack this password to gain access to the Windows machine hosting the Jupyter server, or access other network-accessible machines or 3rd party services using that credential. Or an attacker perform an NTLM relay attack without cracking the credential to gain access to other network-accessible machines. This vulnerability is fixed in 2.14.1.

Certain Anpviz products allow unauthenticated users to download the running configuration of the device via a HTTP GET request to /ConfigFile.ini or /config.xml URIs. This configuration file contains usernames and encrypted passwords (encrypted with a hardcoded key common to all devices). This affects IPC-D250, IPC-D260, IPC-B850, IPC-D850, IPC-D350, IPC-D3150, IPC-D4250, IPC-D380, IPC-D880, IPC-D280, IPC-D3180, MC800N, YM500L, YM800N_N2, YMF50B, YM800SV2, YM500L8, and YM200E10 firmware v3.2.2.2 and lower and possibly more vendors/models of IP camera.

An issue in TP-Link AX10 Ax1500 v.1.3.10 Build (20230130) allows a remote attacker to obtain sensitive information

Prometheus is an open-source monitoring system and time series database. Prior to versions 3.5.3 and 3.11.3, the client_secret field in the Azure AD remote write OAuth configuration (storage/remote/azuread) was typed as string instead of Secret. Prometheus redacts fields of type Secret when serving the configuration via the /-/config HTTP API endpoint. Because the field was a plain string, the Azure OAuth client secret was exposed in plaintext to any user or process with access to that endpoint. This issue has been patched in versions 3.5.3 and 3.11.3.

Information disclosure in the Graphics: WebGPU component. This vulnerability was fixed in Firefox 151 and Thunderbird 151.

An issue in CSS Exfil Protection v.1.1.0 allows a remote attacker to obtain sensitive information due to missing support for CSS Style Rules.

Vite, a provider of frontend development tooling, has a vulnerability in versions prior to 6.2.3, 6.1.2, 6.0.12, 5.4.15, and 4.5.10. `@fs` denies access to files outside of Vite serving allow list. Adding `?raw??` or `?import&raw??` to the URL bypasses this limitation and returns the file content if it exists. This bypass exists because trailing separators such as `?` are removed in several places, but are not accounted for in query string regexes. The contents of arbitrary files can be returned to the browser. Only apps explicitly exposing the Vite dev server to the network (using `--host` or `server.host` config option) are affected. Versions 6.2.3, 6.1.2, 6.0.12, 5.4.15, and 4.5.10 fix the issue.

Joomla! 1.7.1 has core information disclosure due to inadequate error checking.

The Advanced Woo Search plugin version through 1.99 for Wordpress suffers from a sensitive information disclosure vulnerability in every ajax search request via the sql field to includes/class-aws-search.php.

Vulnerability in the Oracle WebCenter Sites product of Oracle Fusion Middleware (component: WebCenter Sites). Supported versions that are affected are 12.2.1.4.0 and 14.1.2.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle WebCenter Sites. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle WebCenter Sites accessible data. CVSS 3.1 Base Score 7.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).