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
44 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact With Jetty 12+ a user can craft a URL to access any resource the Jetty instance is allowed to access. For example http://[host]/xwiki/bin/skin/..%252f/..%252f..%252f..%252f..%252f..%252f..%252f..%252fetc/passwd allows downloading the content of the /etc/passwd file, provided Jetty is allowed to read it, and if your XWiki webapp is located exactly 5 levels below / (like /var/lib/jetty/webapps/xwiki, which is the case in the docker image, for example). Another example which does not go out of the XWiki webapp, but it's still a vulnerability (since users should not be allowed to access Hibernate or XWiki configuration files) is http://[host]/xwiki/bin/skin/..%252f/..%252fWEB-INF/xwiki.cfg. Patches This vulnerability has been patched in XWiki 17.10.5 and 18.2.0. Workarounds A possible workaround is to use a different application server, like Jetty < 12 (in the case of XWiki < 17) or Tomcat, which don't seem to be impacted. Resources https://jira.xwiki.org/browse/XWIKI-24075…
Recommended action: Upgrade to 18.2.0 or 17.10.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact REST API endpoints like /xwiki/rest/wikis/xwiki/spaces/AnnotationCode/pages/AnnotationConfig/objects/AnnotationCode.AnnotationConfig/0/properties list all available pages as part of the metadata for database list properties, which can exhaust available resources on large wikis. Patches This problem has been patched by applying the configured query limit also to the available values for database list properties in XWiki 16.10.16, 17.4.8 and 17.10.1. Workarounds We're not aware of any workarounds apart from upgrading the affected modules.
Recommended action: Upgrade to 17.10.1, 17.4.8 or 16.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 An improperly protected scripting API allows any user with script right to bypass the sandboxing of the Velocity scripting API and execute, e.g., arbitrary Python scripts, allowing full access to the XWiki instance and thereby compromising the confidentiality, integrity and availability of the whole instance. Note that script right already constitutes a high level of access that we don't recommend giving to untrusted users. Patches The vulnerability has been patched in XWiki 17.4.8 and 17.10.1 by requiring programming right to access the affected scripting API. Workarounds We're not aware of any workarounds except for being careful whom you grant script right. Attribution We thank Youssef Azefzaf for discovering and reporting this vulnerability.
Recommended action: Upgrade to 17.10.1 or 17.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 XML export of a page in XWiki that can be triggered by any user with view rights on a page by appending ?xpage=xml to the URL includes password and email properties stored on a document that aren't named password or email. This allows any user to obtain the salted and hashed user account validation or password reset token. As those tokens are randomly generated strings, the immediate impact of this should be low. The user's password and email itself aren't exposed as those fields are named password and email and thus aren't affected. However, depending on how the wiki is used, there could be extensions or custom code that store passwords in plain text in such password properties that would be exposed by this vulnerability. Patches This vulnerability has been fixed by completely removing the output of password and email fields in this XML export in versions 17.2.0 RC1, 16.10.5 and 16.4.7. Workarounds If this XML export isn't needed, the file templates/xml.vm in the deployed…
Recommended action: Upgrade to 17.2.0-rc-1 (pre-release), 16.10.5 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.
Impact Any user with edit right on a page of the wiki can create an XClass with a database list property that references a password property, for example the password hash that is stored for users. When adding an object of that XClass, the content of that password property is displayed. In practice, with a standard rights setup, this means that any user with an account on the wiki can access password hashes of all users, and possibly other password properties (with hashed or plain storage) that are on pages that the user can view. Patches This vulnerability has been pached in XWiki 16.4.7, 16.10.5, and 17.2.0 by disallowing the use of password properties in database list properties. Additionally, queries for email properties are disallowed, too, when email obfuscation is enabled. Workarounds We're not aware of any workarounds.
Recommended action: Upgrade to 17.2.0-rc-1 (pre-release), 16.10.5 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.
Impact It's possible to execute any SQL query in Oracle by using the function like DBMSXMLGEN or DBMSXMLQUERY. The XWiki#searchDocuments APIs are not sanitizing the query at all and even if they force a specific select, Hibernate allows using any native function in an HQL query (for example in the WHERE). Patches This has been patched in 16.10.6 and 17.3.0-rc-1. Workarounds There is no known workaround, other than upgrading XWiki. References https://jira.xwiki.org/browse/XWIKI-22728 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 17.3.0-rc-1 (pre-release) or 16.10.6 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 XWiki user with edit right on at least one App Within Minutes application (the default for all users XWiki) can obtain programming right/perform remote code execution by editing the application. The detailed reproduction steps can be found in the original bug report. Patches This vulnerability has been fixed in XWiki 17.0.0, 16.4.7, and 16.10.3. Workarounds Restricting edit rights on all existing App Within Minutes applications to trusted users mitigates at least the PoC exploit, but we can't exclude that there are other ways to exploit this vulnerability.
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.
Impact It's possible to execute any SQL query in Oracle by using the function like DBMSXMLGEN or DBMSXMLQUERY. The XWiki query validator does not sanitize functions that would be used in a simple select and Hibernate allows using any native function in an HQL query. Patches This has been patched in 16.10.2, 16.4.7 and 15.10.16. Workarounds There is no known workaround, other than upgrading XWiki. References https://jira.xwiki.org/browse/XWIKI-22734 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 16.10.2, 16.4.7 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 It is possible for a user with SCRIPT right to escape from the HQL execution context and perform a blind SQL injection to execute arbitrary SQL statements on the database backend. 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. For example, with a MySQL or MariaDB database, you can use the following script (which a user having SCRIPT right but not PROGRAMMING right) to get the content of the xwikistrings table (which contain all the short string fields stored in objects, including passwords): Patches This has been patched in 16.10.1, 16.4.6 and 15.10.16. Workarounds There is no known workaround, other than upgrading XWiki. The protection added to this REST API is the same as the one used to validate…
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 Is it possible for a user without Script or Programming rights to craft a URL pointing to a page with arbitrary JavaScript. This requires social engineer to trick a user to follow the URL. Reproduction steps 1. As a user without script or programming right, create a (non-terminal) document named " + alert(1) + " (the quotes need to be part of the name). 1. Edit the class. 1. Add a string property named "test". 1. Edit using the object editor and add an object of the created class 1. Get an admin to open <xwiki-server/xwiki/bin/view/%22%20%2B%20alert(1)%20%2B%20%22/?viewer=display&type=object&property=%22%20%2B%20alert(1)%20%2B%20%22.WebHome.test&mode=edit where <xwiki-server is the URL of your XWiki installation. Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0. Workarounds We're not aware of any workaround except upgrading. References - https://jira.xwiki.org/browse/XWIKI-21810 -…
Recommended action: Upgrade to 16.0.0, 15.10.6, 15.5.5 or 14.10.21 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 who can edit any page like their profile can create a custom skin with a template override that is executed with programming right, thus allowing remote code execution. To reproduce, as a user without edit, script or admin right, add an object of class XWiki.XWikiSkins to your profile. Name it whatever you want and set the Base Skin to flamingo. Add an object of class XWikiSkinFileOverrideClass and set the path to macros.vm and the content to: Back to your profile, click Test this skin. Force a refresh, just in case. If the error "Skin - I got programming: true" gets logged, the installation is vulnerable. Patches This has been patched in XWiki 14.10.19, 15.5.4 and 15.10RC1. Workarounds We're not aware of any workaround except upgrading. References https://jira.xwiki.org/browse/XWIKI-21478 https://github.com/xwiki/xwiki-platform/commit/3d4dbb41f52d1a6e39835cfb1695ca6668605a39 (= 15.8 RC1)…
Recommended action: Upgrade to 15.10-rc-1 (pre-release), 15.5.4 or 14.10.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Remote code execution is possible via PDF export templates. To reproduce on an installation, register a new user account with username PDFClass if XWiki.PDFClass does not exist. On XWiki.PDFClass, use the class editor to add a "style" property of type "TextArea" and content type "Plain Text". Then, add an object of class PDFClass and set the "style" attribute to $services.logging.getLogger('PDFClass').error("I got programming: $services.security.authorization.hasAccess('programming')"). Finally, go to <host/xwiki/bin/export/Main/WebHome?format=pdf&pdftemplate=XWiki.PDFClass. If the logs contain "ERROR PDFClass - I got programming: true", the instance is vulnerable. Patches This vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10-rc-1. Workarounds If PDF templates are not typically used on the instance, an administrator can create the document XWiki.PDFClass and block its edition, after making sure that it does not contain a style attribute. Otherwise, the…
Recommended action: Upgrade to 15.10-rc-1 (pre-release), 15.5.4 or 14.10.20 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 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. Now 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…
Recommended action: Upgrade to 15.9-rc-1 (pre-release), 15.5.4 or 14.10.19 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 rollback action is missing a right protection: it means that a user can rollback to a previous version of the page to gain rights they don't have anymore. This vulnerability impacts all version of XWiki since rollback action is available. Patches The problem has been patched in XWiki 14.10.16, 15.5.3 and 15.8-rc-1 by ensuring that the rights are checked before performing the rollback. Workarounds There's no workaround for this vulnerability, except paying attention to delete old versions of documents that could allow users to gain more rights. References JIRA ticket: https://jira.xwiki.org/browse/XWIKI-21257 Commit: 4de72875ca49602796165412741033bfdbf1e680 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.10.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In XWiki Platform, it's possible for a user to execute any content with the right of an existing document's content author, provided the user have edit right on it. The reason for this is that the edit action sets the content without modifying the content author. To reproduce: Log in as a user without programming or script right. Open the URL <xwiki-host/xwiki/bin/edit/<document/?content=%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D&xpage=view, where <xwiki-host is the URL of your XWiki installation and <document is the path to a document whose content author has programming right (or script right) and on which the current user has edit right. The text "Hello from Groovy!" is displayed in the page content, showing that the Groovy macro has been executed, which should not be the case for a user without programming right. Patches This has been patched in XWiki 14.10.6 and 15.2RC1. Workarounds There are no known workarounds for it. References…
Recommended action: Upgrade to 15.2-rc-1 (pre-release) or 14.10.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In XWiki Platform, it's possible to execute content with the right of any user if you can make this user follow a crafted URL. This is possible because edit action sets and thereby executes the page content without checking for a cross-site request forgert (CSRF) token. To reproduce: Get a user with programming rights to visit the URL <xwiki-host/xwiki/bin/edit/Main/?content=%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D&xpage=view, where <xwiki-host is the URL of your XWiki installation. This can be done by embedding an image with this URL. The text "Hello from Groovy!" is displayed in the page content, showing that the Groovy macro has been executed. Patches This has been patched in XWiki 14.10.7 and 15.2-RC-1. Workarounds There are no known workarounds for it. References https://jira.xwiki.org/browse/XWIKI-20386 https://github.com/xwiki/xwiki-platform/commit/cf8eb861998ea423c3645d2e5e974420b0e882be For more information If you have any…
Recommended action: Upgrade to 15.2-rc-1 (pre-release) or 14.10.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When a document has been deleted and re-created, it is possible for users with view right on the re-created document but not on the deleted document to view the contents of the deleted document. Such a situation might arise when rights were added to the deleted document. This can be exploited through the diff feature and, partially, through the REST API by using versions such as deleted:1 (where the number counts the deletions in the wiki and is thus guessable). Given sufficient rights, the attacker can also re-create the deleted document, thus extending the scope to any deleted document as long as the attacker has edit right in the location of the deleted document. Patches This vulnerability has been patched in XWiki 14.10.8 and 15.3 RC1 by properly checking rights when deleted revisions of a document are accessed. Workarounds The only workaround is to regularly clean deleted documents to minimize the potential exposure. Extra care should be taken when deleting sensitive…
Recommended action: Upgrade to 15.3-rc-1 (pre-release) 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 It is possible in XWiki to execute Velocity code without having script right by creating an XClass with a property of type "TextArea" and content type "VelocityCode" or "VelocityWiki". For the former, the syntax of the document needs to be set the xwiki/1.0 (this syntax doesn't need to be installed). In both cases, when adding the property to an object, the Velocity code is executed regardless of the rights of the author of the property (edit right is still required, though). In both cases, the code is executed with the correct context author so no privileged APIs can be accessed. However, Velocity still grants access to otherwise inaccessible data and APIs that could allow further privilege escalation. At least for "VelocityCode", this behavior is most likely very old but only since XWiki 7.2, script right is a separate right, before that version all users were allowed to execute Velocity and thus this was expected and not a security issue. Patches This has been patched in…
Recommended action: Upgrade to 15.4-rc-1 (pre-release) or 14.10.10 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 create action is vulnerable to a CSRF attack, allowing script and thus remote code execution when targeting a user with script/programming right, thus compromising the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, the XWiki syntax [[image:path:/xwiki/bin/create/Foo/WebHome?template=&parent=Main.WebHome&title=$services.logging.getLogger(%22foo%22).error(%22Script%20executed!%22)]] can be added to any place that supports XWiki syntax like a comment. When a user with script right views this image and a log message ERROR foo - Script executed! appears in the log, the XWiki installation is vulnerable. Patches This has been patched in XWiki 14.10.9 and 15.4RC1 by requiring a CSRF token for the actual page creation. Workarounds There are no known workarounds. References https://jira.xwiki.org/browse/XWIKI-20849 https://github.com/xwiki/xwiki-platform/commit/4b20528808d0c311290b0d9ab2cfc44063380ef7
Recommended action: Upgrade to 15.4-rc-1 (pre-release) or 14.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 When an XWiki installation is upgraded and that upgrade contains a fix for a bug in a document, just a new version of that document is added. In some cases, it's still possible to exploit the vulnerability that was fixed in the new version. The severity of this depends on the fixed vulnerability, for the purpose of this advisory take CVE-2022-36100 as example - it is easily exploitable with just view rights and critical. When XWiki is upgraded from a version before the fix for it (e.g., 14.3) to a version including the fix (e.g., 14.4), the vulnerability can still be reproduced by adding rev=1.1 to the URL used in the reproduction steps so remote code execution is possible even after upgrading. Therefore, this affects the confidentiality, integrity and availability of the whole XWiki installation. This vulnerability also affects manually added script macros that contained security vulnerabilities that were later fixed by changing the script macro without deleting the versions…
Recommended action: Upgrade to 15.2-rc-1 (pre-release) or 14.10.7 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's possible to perform an XSS by forging a request to a delete attachment action with a specific attachment name. Now this XSS can be exploited only if the attacker knows the CSRF token of the user, or if the user ignores the warning about the missing CSRF token. Patches The vulnerability has been patched in XWiki 15.1-rc-1 and XWiki 14.10.6. Workarounds There's no workaround for this other than upgrading XWiki. References Jira ticket: https://jira.xwiki.org/browse/XWIKI-20339 Commit containing the fix: https://github.com/xwiki/xwiki-platform/commit/35e9073ffec567861e0abeea072bd97921a3decf 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-rc-1 (pre-release) or 14.10.6 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's possible to exploit well known parameters in XWiki URLs to perform redirection to untrusted site. This vulnerability was partially fixed in the past for XWiki 12.10.7 and 13.3RC1 but there is still the possibility to force specific URLs to skip some checks, e.g. using URLs like http:example.com in the parameter would allow the redirect. Patches The issue has now been patched against all patterns that we know about for performing redirect. It also performs a real URI parsing that should protect in most cases. This has been patched in XWiki 14.10.4 and 15.0. Workarounds The only workaround is to upgrade XWiki. References JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20096 JIRA ticket about the improvment actually fixing the vulnerability: https://jira.xwiki.org/browse/XWIKI-20549 Previous advisory about open redirect: https://github.com/advisories/GHSA-jp55-vvmf-63mv For more information If you have any questions or comments about this advisory: Open an issue in Jira…
Recommended action: Upgrade to 14.10.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It's possible to display any page you cannot access through the combination of the async and display macro. Steps to reproduce: 1. Enable comments for guests by giving guests comment rights 2. As a guest, create a comment with content 3. Open the comments viewer from the menu (appends ?viewer=comments to the URL) - the Menu.WebHome is displayed while the expectation would be to have an error that the current user is not allowed to see it Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8, and 13.10.11. Workarounds There is no known workaround. References https://jira.xwiki.org/browse/XWIKI-20394 https://jira.xwiki.org/browse/XRENDERING-694 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.10.3, 14.4.8 or 13.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 Any user who can edit their own user profile can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. The following syntax, to be put, e.g., in the about section of the user profile, demonstrates a proof of concept: While it would be expected that the above code is displayed just without the ~, in fact just "1" is displayed, followed by a lot of raw HTML code. The same vulnerability can also be exploited in other contexts where the display method on a document is used to display a field with wiki syntax, for example in applications created using App Within Minutes. Patches This has been patched in XWiki 13.10.11, 14.4.8, 14.10.2 and 15.0RC1. Workarounds There is no workaround apart from upgrading. References https://jira.xwiki.org/browse/XWIKI-20327 https://github.com/xwiki/xwiki-platform/commit/0d547181389f7941e53291af940966413823f61c For more information If you…
Recommended action: Upgrade to 14.10.2, 14.4.8 or 13.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 It is possible to bypass the existing security measures put in place to avoid open redirect by using a redirect such as //mydomain.com (i.e. omitting the http:). It was also possible to bypass it when using URL such as http:/mydomain.com. Patches The problem has been patched on XWiki 13.10.10, 14.4.4 and 14.8RC1. Workarounds The only way to workaround the bug is by providing a patched jar of xwiki-platform-oldcore containing the following changes: https://github.com/xwiki/xwiki-platform/commit/e4f7f68e93cb08c25632c126356d218abf192d1e#diff-c445f288d5d63424f56ef13f65514ab4e174a72e979b53b88197c2b7def267cf. References Jira ticket of the reported vulnerability: https://jira.xwiki.org/browse/XWIKI-19994 Jira ticket of the original mechanism put in place to prevent open redirect: https://jira.xwiki.org/browse/XWIKI-10309 Original advisory about open redirect: https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-jp55-vvmf-63mv For more information If you have any questions…
Recommended action: Upgrade to 14.8-rc-1 (pre-release), 14.4.4 or 13.10.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.