Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
16.10.1717.4.917.10.318.1.0-rc-1· Vendor fix available
Issue
Impact POST /wikis/{wikiName} executes a XAR import without performing any authentication or authorization checks, allowing an unauthenticated attacker to create or update documents in the target wiki Patches This vulnerability has been patched in XWiki 16.10.17, 17.4.9, 17.10.3, 18.0.1 and 18.1.0-rc-1. Workarounds XWiki is not aware of any workarounds other than adding a rule into an HTTP proxy to prevent access POST request in the /wikis/{wikiName}[/] endpoint. Resources https://jira.xwiki.org/browse/XWIKI-23953 https://github.com/xwiki/xwiki-platform/commit/4b7b95b79256374d487e9ece1dc48f527966990f For more information If there are any questions or comments about this advisory: Open an issue in Jira XWiki.org Send an email to the Security Mailing List Attribution Reported by Sho Odagiri (GMO Cybersecurity by Ierae, Inc.).
Recommended action: Upgrade to 18.1.0-rc-1 (pre-release), 17.10.3, 17.4.9 or 16.10.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact XWiki's REST API doesn't enforce any limits for the number of items that can be requested in a single request at the moment. Depending on the number of pages in the wiki and the memory configuration, this can lead to slowness and unavailability of the wiki. As an example, the /rest/wikis/xwiki/spaces resource returns all spaces on the wiki by default, which are basically all pages. Patches XWiki 17.7.0RC1, 17.4.4 and 16.10.11 introduce a configurable limit, limiting responses to 1000 items by default. Requesting larger limits leads to an error now. Workarounds We're not aware of any workaround, except denying access to the affected REST resources in a proxy in front of XWiki.
Recommended action: Upgrade to 17.7.0-rc-1 (pre-release), 17.4.4 or 16.10.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The REST search URL is vulnerable to HQL injection via the orderField parameter. The specified value is added twice in the query, though, once in the field list for the select and once in the order clause, so it's not that easy to exploit. The part of the query between the two fields can be enclosed in single quotes to effectively remove them, but the query still needs to remain valid with the query two times in it. For example, with the following orderField parameter: See the following error: For reference, the full URL for the above error is: Patches This has been patched in 17.5.0, 17.4.2, 16.10.9. Workarounds There is no known workaround, other than upgrading XWiki. Resources https://jira.xwiki.org/browse/XWIKI-23247 https://github.com/xwiki/xwiki-platform/commit/743ebf8696ffa55161ed2c5ecf26b09f69e6bcf1 https://github.com/xwiki/xwiki-platform/commit/a45eca2af772abb7324e56d7fd2df1ac937bc445 For more information If you have any questions or comments about this advisory: Open…
Recommended action: Upgrade to 17.4.2 or 16.10.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches 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. Workarounds We're not aware of any workarounds.
Recommended action: Upgrade to 17.0.0, 16.10.3 or 16.4.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
14.10.2216.4.315.10.1216.7.0· Vendor fix available
Issue
Impact Anyone can access the metadata of any attachment in the wiki using the wiki attachment REST endpoint. It's not filtering the result depending on current user rights, a not authenticated user could exploit this even in a totally private wiki. To reproduce: remove view from guest on the whole wiki logout access http://127.0.0.1:8080/xwiki/rest/wikis/xwiki/spaces/Sandbox/pages/WebHome/attachments You get a list of attachments, while the expected result should be an empty list. Patches This vulnerability has been fixed in XWiki 14.10.22, 15.10.12, 16.7.0-rc-1 and 16.4.3. Workarounds We're not aware of any workaround except upgrading. References https://jira.xwiki.org/browse/XWIKI-22424 https://jira.xwiki.org/browse/XWIKI-22427 https://github.com/xwiki/xwiki-platform/commit/a43e933ddeda17dad1772396e1757998260e9342#diff-0 For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List Attribution Issue…
Recommended action: Upgrade to 16.7.0, 16.4.3, 15.10.12 or 14.10.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It is possible for a remote unauthenticated user to escape from the HQL execution context and perform a blind SQL injection to execute arbitrary SQL statements on the database backend, including when "Prevent unregistered users from viewing pages, regardless of the page rights" and "Prevent unregistered users from editing pages, regardless of the page rights" options are enabled. Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries. The vulnerability may be tested in a default installation of XWIki Standard Flavor, including using the official Docker containers. An example query, which leads to SQL injection with MySQL/MariaDB backend is shown below: When executed, the response from the server will come after a delay of 10 extra seconds, indicating successful execution of the injected SQL statement. An example of a query for the…
Recommended action: Upgrade to 16.10.1, 16.4.6 or 15.10.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Protected pages are listed when requesting the REST endpoints /rest/wikis/[wikiName]/pages even if the user doesn't have view rights on them. It's particularly true if the entire wiki is protected with "Prevent unregistered user to view pages": the endpoint would still list the pages of the wiki (actually it only impacts the main wiki due to XWIKI-22639). Patches The problem has been patched in XWiki 15.10.14, 16.4.6, 16.10.0RC1. In those versions the endpoint can still be requested but the result is filtered out based on pages rights. Workarounds There's no workaround except upgrading or applying manually the changes of the commits (see references) in xwiki-platform-rest-server and recompiling / rebuilding it. References Original JIRA ticket: https://jira.xwiki.org/browse/XWIKI-22630 Related JIRA ticket: https://jira.xwiki.org/browse/XWIKI-22639 Commits of the patch: https://github.com/xwiki/xwiki-platform/commit/bca72f5ce971a31dba2a016d8dd8badda4475206 and…
Recommended action: Upgrade to 16.10.0-rc-1 (pre-release), 16.4.6 or 15.10.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The REST API exposes the history of any page in XWiki of which the attacker knows the name. The exposed information includes for each modification of the page the time of the modification, the version number, the author of the modification (both username and displayed name) and the version comment. This information is exposed regardless of the rights setup, and even when the wiki is configured to be fully private. On a private wiki, this can be tested by accessing /xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome/history, if this shows the history of the main page then the installation is vulnerable. Patches This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1. Workarounds There aren't any known workarounds apart from upgrading to a fixed version. References https://jira.xwiki.org/browse/XWIKI-22052 https://github.com/xwiki/xwiki-platform/commit/9cbca9808300797c67779bb9a665d85cf9e3d4b8
Recommended action: Upgrade to 16.3.0-rc-1 (pre-release) or 15.10.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The REST API allows executing all actions via POST requests and accepts text/plain, multipart/form-data or application/www-form-urlencoded as content types which can be sent via regular HTML forms, thus allowing cross-site request forgery. With the interaction of a user with programming rights, this allows remote code execution through script macros and thus impacts the integrity, availability and confidentiality of the whole XWiki installation. For regular cookie-based authentication, the vulnerability is mitigated by SameSite cookie restrictions but as of March 2023, these are not enabled by default in Firefox and Safari. Patches The vulnerability has been patched in XWiki 14.10.8 and 15.2 by requiring a CSRF token header for certain request types that are susceptible to CSRF attacks. Workarounds It is possible to check for the Origin header in a reverse proxy to protect the REST endpoint from CSRF attacks, see the Jira issue for an example configuration. References…
Recommended action: Upgrade to 15.2 or 14.10.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Any user can call a REST endpoint and obtain the obfuscated passwords (even when the mail obfuscation is activated). For instance, by calling http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/U1/objects/XWiki.XWikiUsers/0 when user U1 exists on wiki xwiki. Patches The issue has been patched on XWiki 14.4.8, 14.10.6, and 15.1 Workarounds There is no known workaround. It is advised to upgrade to one of the patched versions. References - https://jira.xwiki.org/browse/XWIKI-16138 - https://github.com/xwiki/xwiki-platform/commit/824cd742ecf5439971247da11bfe7e0ad2b10ede For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List
Recommended action: Upgrade to 15.1, 14.10.6 or 14.4.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 (e.g., comments, page names...). Patches Users should upgrade to XWiki 14.6+, 14.4.3+, or13.10.8+. Older versions have not been patched. Workarounds No known workaround. References - Patch: https://github.com/xwiki/xwiki-platform/commit/38dc1aa1a4435f24d58f5b8e4566cbcb0971f8ff - Jira issue: https://jira.xwiki.org/browse/XWIKI-19997 For more information If you have any questions or comments about this advisory: - Open an issue in Jira XWiki.org - Email us at Security Mailing List
Recommended action: Upgrade to 14.6, 14.4.3 or 13.10.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.