See how xwiki compares to other vendors in security performance
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.).
Impact
It's possible to get 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 can apparently be reproduced on Tomcat instances.
Patches
This has been patched in 18.0.0-rc-1, 17.10.3, 17.4.9, 16.10.17.
Workarounds
There is no known workaround, other than upgrading XWiki.
References
https://jira.xwiki.org/browse/XCOMMONS-3547 https://github.com/xwiki/xwiki-commons/commit/a979cafd89f6a9c9c0b9ab19744d672df64429bf
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
The vulnerability was reported by Michał Kołek.
Impact
Anyone who has view rights on the Calendar.JSONService page, including guest users can exploit this vulnerability by accessing database info or starting a DoS attack.
Workarounds
Remove the Calendar.JSONService page. This will however break some functionalities.
References
Jira issue: FULLCAL-80: SQL injection through Calendar.JSONService FULLCAL-81: SQL injection through Calendar.JSONService still exists
For more information
If there are any questions or comments about this advisory: Open an issue in Jira XWiki.org Email Security Mailing List
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:
doc.fullName%20from%20XWikiDocument%20as%20doc%20where%20%24%24%3D'%24%24%3Dconcat(chr(61)%2Cchr(39))%20and%20version()%7C%7Cpgsleep(1)%3Dversion()%7C%7Cpgsleep(1)%20and%20(1%3D1%20or%20%3F%3D%3F%20or%20%3F%3D%3F%20or%20%3F%3D%3F%20or%20%3F%3D%3F%20or%20%3F%3D%3F)%20--%20comment'%20or%20a%3D'%20order%20by%20doc.fullName See the following error:
QuerySyntaxException: unexpected token: $$ near line 1, column 518 [select distinct doc.fullName, doc.space, doc.name, doc.language, doc.doc.fullName from com.xpn.xwiki.doc.XWikiDocument as doc where (doc.hidden <> true or doc.hidden is null) and ($$='$$=concat(chr(61),chr(39)) and version()||pgsleep(1)=version()||pgsleep(1) and (1=1 or ?=? or ?=? or ?=? or ?=? or ?=?) -- comment' or a=') order by doc.fullName from com.xpn.xwiki.doc.XWikiDocument as doc where ( (upper(doc.title) like :keywords) ) order by doc.doc.fullName from com.xpn.xwiki.doc.XWikiDocument as doc where $$='$$=concat(chr(61),chr(39)) and version()||pgsleep(1)=version()||pgsleep(1) and (1=1 or ?=? or ?=? or ?=? or ?=? or ?=?) -- comment' or a=' order by doc.fullName asc]
For reference, the full URL for the above error is:
http://localhost:8080/xwiki/rest/wikis/xwiki/search?q=test&scope=title&orderField=doc.fullName%20from%20XWikiDocument%20as%20doc%20where%20%24%24%3D%27%24%24%3Dconcat(chr(61)%2Cchr(39))%20and%20version()%7C%7Cpgsleep(1)%3Dversion()%7C%7Cpgsleep(1)%20and%20(1%3D1%20or%20%3F%3D%3F%20or%20%3F%3D%3F%20or%20%3F%3D%3F%20or%20%3F%3D%3F%20or%20%3F%3D%3F)%20--%20comment%27%20or%20a%3D%27%20order%20by%20doc.fullName
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 an issue in Jira XWiki.org Email us at Security Mailing List
Impact
Anyone with VIEW access to a user profile can create a token for that user. If that XWiki instance is configured to allow token authentication, it allows authentication with any user (since users are very commonly viewable, at least to other registered users).
Patches
Version 2.18.2.
Workarounds
The only workaround is to disable token access.
References
https://jira.xwiki.org/browse/OIDC-240 https://github.com/xwiki-contrib/oidc/commit/d90d717172283aaa96bb5bb44e357f910ae64adb
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
XWiki Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Starting in version 1.0 and prior to version 1.26.5, missing escaping of the title in the confluence paste code macro allows remote code execution for any user who can edit any page. The classes parameter is used without escaping in XWiki syntax, thus allowing XWiki syntax injection which enables remote code execution. Version 1.26.5 has a fix for the issue.
XWiki Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Starting in version 1.0 and prior to version 1.26.5, missing escaping of the ac:type in the ConfluenceLayoutSection macro allows remote code execution for any user who can edit any page The classes parameter is used without escaping in XWiki syntax, thus allowing XWiki syntax injection which enables remote code execution. Version 1.26.5 has a fix for the issue.
XWiki Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Starting in version 1.0 and prior to version 1.26.5, missing escaping of the classes parameter in the panel macro allows remote code execution for any user who can edit any page The classes parameter is used without escaping in XWiki syntax, thus allowing XWiki syntax injection which enables remote code execution. Version 1.26.5 contains a patch for the issue.
XWiki Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Starting in version 1.0 and prior to version 1.26.5, missing escaping of the width parameter in the column macro allows remote code execution for any user who can edit any page or who can access the CKEditor converter. The width parameter is used without escaping in XWiki syntax, thus allowing XWiki syntax injection which enables remote code execution when the macro has been installed by a user with programming right, or it at least allows executing Velocity code as the wiki admin. Version 1.26.5 contains a patch for the issue.
Impact
It's possible to get 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 can apparently be reproduced on Tomcat instances.
Patches
This has been patched in 17.4.0-rc-1, 16.10.7.
Workarounds
There is no known workaround, other than upgrading XWiki.
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
The vulnerability was reported by Gregor Neumann.
Impact
It's possible to get access and read configuration files by using URLs such as http://localhost:8080/xwiki/webjars/wiki%3Axwiki/..%2F..%2F..%2F..%2F..%2FWEB-INF%2Fxwiki.cfg. The trick here is to encode the / which is decoded when parsing the URL segment, but not re-encoded when assembling the file path.
Patches
This has been patched in 17.4.0-rc-1, 16.10.7.
Workarounds
There is no known workaround, other than upgrading XWiki.
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
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
Impact
It's possible for anyone to inject SQL using the parameter sort of the getdeleteddocuments.vm. It's injected as is as an ORDER BY value.
One can see the result of the injection with http://127.0.0.1:8080/xwiki/rest/liveData/sources/liveTable/entries?sourceParams.template=getdeleteddocuments.vm&sort=injected (this example does not work, but it shows that an HQL query was executed with the passed value which look nothing like an order by value, without any kind of sanitation).
Patches
This has been patched in 17.3.0-rc-1, 16.10.6.
Workarounds
There is no known workaround, other than upgrading XWiki.
References
https://jira.xwiki.org/browse/XWIKI-23093
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
The vulnerability was identifier by Aleksey Solovev from Positive Technologies.
Impact
The default macro content parser didn't preserve the restricted attribute of the transformation context when executing nested macros. This allows executing macros that are normally forbidden in restricted mode, in particular script macros. The cache and chart macros that are bundled in XWiki use the vulnerable feature. The following XWiki syntax, when used inside a comment in XWiki, demonstrates the privilege escalation from comment right to programming right and thus remote code execution (RCE) that is possible due to this:
{{cache}}{{groovy}}println("Hello from Groovy!"){{/groovy}}{{/cache}}
This vulnerability exists since the restricted attribute has been added to the transformation context in version 4.2.
Patches This has been patched in XWiki 13.10.11, 14.4.7 and 14.10.
Workarounds To avoid the exploitation of this bug, comments can be disabled for untrusted users until an upgrade to a patched version has been performed. Note that users with edit rights will still be able to add comments via the object editor even if comments have been disabled.
Resources https://github.com/xwiki/xwiki-rendering/commit/c73fa3ccd4ac59057e48e5d4325f659e78e8f86d https://jira.xwiki.org/browse/XRENDERING-689 https://jira.xwiki.org/browse/XWIKI-20375
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
This vulnerability has been reported on Intigriti by René de Sain @renniepak.
Impact The XHTML syntax depended on the xdom+xml/current syntax which allows the creation of raw blocks that permit the insertion of arbitrary HTML content including JavaScript. This allows XSS attacks for users who can edit a document like their user profile (enabled by default). The attack works by setting the document's syntax to xdom+xml/current and then inserting content like <document><p><metadata><metadata><entry><string>syntax</string><org.xwiki.rendering.syntax.Syntax><type><name>XHTML</name><id>xhtml</id><variants class="empty-list"></variants></type><version>5</version></org.xwiki.rendering.syntax.Syntax></entry></metadata></metadata></p><rawtext syntax="html/5.0" content="<script>alert(1);</script>"></rawtext></document>
This has been fixed by removing the dependency on the xdom+xml/current syntax from the XHTML syntax. Note that the xdom+xml syntax is still vulnerable to this attack. As it's main purpose is testing and its use is quite difficult, this syntax shouldn't be installed or used on a regular wiki. We're currently not aware of any further dependencies on it.
Patches The fix of removing the dependency has been included in XWiki 14.10. It is not released for earlier versions due to the potential breakages, among others this change makes it necessary to update the Confluence XHTML syntax as it relies on internals that were changed for the fix. Similar XSS fixes were also not applied to the LTS version 13.10.x due to the potential breakages.
Workarounds There are no known workarounds apart from upgrading.
References https://jira.xwiki.org/browse/XRENDERING-660 https://github.com/xwiki/xwiki-rendering/commit/a4ca31f99f524b9456c64150d6f375984aa81ea7
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
CryptPad is a collaboration suite. Prior to version 2025.3.0, enforcement of Two-Factor Authentication (2FA) in CryptPad can be trivially bypassed, due to weak implementation of access controls. An attacker that compromises a user's credentials can gain access to the victim's account, even if the victim has 2FA set up. This is due to 2FA not being enforced if the path parameter is not 44 characters long, which can be bypassed by simply URL encoding a single character in the path. This issue has been patched in version 2025.3.0.
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
Impact The Markdown syntax is vulnerable to XSS through HTML. In particular, using Markdown syntax, it's possible for any user to embed Javascript code that will then be executed on the browser of any other user visiting either the document or the comment that contains it. In the instance that this code is executed by a user with admins or programming rights, this issue compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce, on an instance where the CommonMark Markdown Syntax 1.2 extension is installed, log in as a user without script rights. Edit a document and set its syntax to Markdown. Then , add the content <script>alert("XSS")</script> and refresh the page. If an alert appears containing "XSS", then the instance is vulnerable.
Patches This has been patched in version 8.9 of the CommonMark Markdown Syntax 1.2 extension.
Workarounds We're not aware of any workaround except upgrading.
References https://jira.xwiki.org/browse/MARKDOWN-80 https://github.com/xwiki-contrib/syntax-markdown/commit/d136472d6e8a47981a0ede420a9096f88ffa5035
Impact
A user who can access pages located in the XWiki space (by default, anyone) can access the page XWiki.Authentication.Administration and (unless an authenticator is set in xwiki.cfg) switch to another installed authenticator.
Note that, by default, there is only one authenticator available (Standard XWiki Authenticator). So, if no authenticator extension was installed, it's not really possible to do anything for an attacker.
Also, in most cases, if you have installed and are using an SSO authenticator (like OIDC or LDAP for example), the worst an attacker can do is break authentication by switching back to the standard authenticator (that's because it's impossible to login to a user which does not have a stored password, and that's usually what SSO authenticator produce).
Patches
This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1.
Workarounds
You can very easily fix this vulnerability in your instance through right configuration: access the page and children right administration of the page XWiki.Authentication (https://myhost/xwiki/bin/admin/XWiki/Authentication/WebPreferences?editor=spaceadmin§ion=PageAndChildrenRights&space=XWiki.Authentication#|t=usersandgroupstable&p=1&l=10&uorg=groups&wiki=local&clsname=XWiki.XWikiGlobalRights) make sure only admin user have the VIEW right
References
https://jira.xwiki.org/browse/XWIKI-22604 https://github.com/xwiki/xwiki-platform/commit/5efc31cea1501c9a5cb593566fea8b558ff32a2a
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
Impact When editing a page, XWiki warns since version 15.9 when there is content on the page like a script macro that would gain more rights due to the editing. This analysis doesn't consider certain kinds of properties, allowing a user to put malicious scripts in there that will be executed after a user with script, admin, or programming rights edited the page. Such a malicious script could impact the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce, as a user without script right, create a class with a TextArea property, create page with an object of that class and a Velocity macro in its content. Then, as an admin, try editing that page. Normally, there should be a warning but in vulnerable versions of XWiki, there is no warning.
Patches This vulnerability has been patched in XWiki 15.10.8 and 16.2.0.
Workarounds We're not aware of any workarounds apart from not editing pages that might have been edited by untrusted users as a user with script rights, e.g., by using separate user accounts for admin and non-admin tasks.
Impact
When a user with programming right edits a document in XWiki that was last edited by a user without programming right and contains an XWiki.ComponentClass, there is no warning that this will grant programming right to this object. An attacker who created such a malicious object could use this to gain programming right on the wiki. For this, the attacker needs to have edit right on at least one page to place this object and then get an admin user to edit that document.
To reproduce the problem, as a user without programming right, add an object of type XWiki.ComponentClass to any page and then edit the page as a user with programming right. There should be warning displayed, if not, the XWiki installation is vulnerable.
While such a warning didn't exist in any version of XWiki, only in XWiki 15.9 RC1 these kinds of warnings have been introduced which is why this is considered the first version that has this vulnerability. Before that, the advice was to be careful when editing pages edited by untrusted users.
Patches This problem has been patched in XWiki 15.10.2, 16.4.3, and 16.8.0 RC1.
Workarounds We're not aware of any workarounds apart from not editing pages that might have been edited by untrusted users as a user with programming rights, e.g., by using separate user accounts for admin and non-admin tasks.
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:
time curl "http://127.0.0.1:8080/rest/wikis/xwiki/query?q=where%20doc.name=length('a')org.apache.logging.log4j.util.Chars.SPACE%20or%201%3C%3E%271%5C%27%27%20union%20select%201,2,3,sleep(10)%20%23%27&type=hql&distinct=0"
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 PostgreSQL database backend is shown below:
curl "https://127.0.0.1:8080/rest/wikis/xwiki/query?q=where%20%24%24='%24%24=concat(%20chr(%2061%20),(chr(%2039%20))%20)%20;select%201%20--%20comment'&type=hql&distinct=0"
Both requests employ database backend dependent techniques of breaking out of HQL query context, described, for example, here: https://www.sonarsource.com/blog/exploiting-hibernate-injections.
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.
References
https://jira.xwiki.org/browse/XWIKI-22691
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
Sergey Anufrienko from Kaspersky ICS-CERT vulnerability research team reported this vulnerability.
Impact A user that doesn't have programming rights can execute arbitrary code when creating a page using the Migration Page template. A possible attack vector is the following: Create a page and add the following content: confluencepro.job.question.advanced.input={{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}} Use the object editor to add an object of type XWiki.TranslationDocumentClass with scope USER. Access an unexisting page using the MigrationTemplate http://localhost:8080/xwiki/bin/edit/Page123?template=ConfluenceMigratorPro.Code.MigrationTemplate It is expected that {{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}} will be present on the page, however, hello from groovy will be printed. Patches The issue will be fixed as part of v1.2. The fix was added with commit 35cef22
Workarounds There are no known workarounds besides upgrading.
References No references.
Impact Any guest can perform arbitrary remote code execution through a request to SolrSearch. This impacts the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on an instance, without being logged in, go to <host>/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28"Hello%20from"%20%2B%20"%20search%20text%3A"%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D%20. If there is an output, and the title of the RSS feed contains Hello from search text:42, then the instance is vulnerable.
Patches This vulnerability has been patched in XWiki 15.10.11, 16.4.1 and 16.5.0RC1.
Workarounds This line in Main.SolrSearchMacros can be edited to match the rawResponse macro defined here with a content type of application/xml, instead of simply outputting the content of the feed.
References
https://jira.xwiki.org/browse/XWIKI-22149 https://github.com/xwiki/xwiki-platform/commit/67021db9b8ed26c2236a653269302a86bf01ef40
Attribution This vulnerability has been reported by John Kwak for Trend Micro's Zero Day Initiative.
Impact
NOTE: The Realtime WYSIWYG Editor extension was experimental, and thus not recommended, in the versions affected by this vulnerability. It has become enabled by default, and thus recommended, starting with XWiki 16.9.0.
A user with only edit right can join a realtime editing session where others, that where already there or that may join later, have script or programming access rights. This user can then insert script rendering macros that are executed for those users in the realtime session that have script or programming rights. The inserted scripts can be used to gain more access rights.
Here's an example that works with XWiki 15.10.9+ and 16.2.0+:
the attacker starts editing a wiki page in realtime (for which they have edit right) another user, with script or programming access right joins the editing session (e.g. by clicking on a link / URL provided by the attacker) the attacker inserts a script rendering macro, say {{velocity}}I can run scripts{{/velocity}}, in the edited content, using the WYSIWYG editor UI the edited content is reloaded for both the attacker and the other user, in order to render the inserted macro the attacker gets a rendering error message the other user sees "I can run scripts"
The attacker can obviously use more advanced scripts to gain access rights.
Before XWiki 15.10.9 and 16.2.0 the edited content was not re-rendered for all the users in the editing sesesion, but only for the user that inserted the macro. This means that in order to reproduce the problem the other user had to insert or update a macro or save and view the content.
Patches
This vulnerability has been patched in XWiki 15.10.12, 16.4.1 and 16.6.0-rc-1.
Workarounds
To avoid this vulnerability you can:
either disable the realtime WYSIWYG editing by disabling the xwiki-realtime CKEditor plugin from the WYSIWYG editor administration section or uninstall the Realtime WYSIWYG Editor extension (org.xwiki.platform:xwiki-platform-realtime-wysiwyg-ui)
References
https://jira.xwiki.org/browse/XWIKI-21949
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
Impact Any user with script rights can perform arbitrary remote code execution by adding instances of XWiki.ConfigurableClass to any page. This compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on a instance, as a user with script rights, edit your user profile and add an object of type XWiki.ConfigurableClass ("Custom configurable sections"). Set "Display in section" and "Display in category" to other, "Scope" to Wiki and all spaces and "Heading" to: #set($codeToExecute = 'Test') #set($codeToExecuteResult = '{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"){{/groovy}}{{/async}}') Save the page and view it, then add ?sheet=XWiki.AdminSheet&viewer=content§ion=other to the URL. If the logs contain "attacker - Attack from Heading succeeded!", then the instance is vulnerable.
Patches This has been patched in XWiki 15.10.9 and 16.3.0.
Workarounds We're not aware of any workaround except upgrading.
References https://jira.xwiki.org/browse/XWIKI-21207 https://github.com/xwiki/xwiki-platform/commit/8493435ff9606905a2d913607d6c79862d0c168d
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
Impact Any user with an account can perform arbitrary remote code execution by adding instances of XWiki.WikiMacroClass to any page. This compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on a instance, as a connected user without script nor programming rights, go to your user profile and add an object of type XWiki.WikiMacroClass. Set "Macro Id", "Macro Name" and "Macro Code" to any value, "Macro Visibility" to Current User and "Macro Description" to {{async}}{{groovy}}println("Hello from User macro!"){{/groovy}}{{/async}}. Save the page, then go to <host>/xwiki/bin/view/XWiki/XWikiSyntaxMacrosList. If the description of your new macro reads "Hello from User macro!", then your instance is vulnerable.
Patches This vulnerability has been fixed in XWiki 15.10.11, 16.4.1 and 16.5.0.
Workarounds It is possible to manually apply this patch to the page XWiki.XWikiSyntaxMacrosList.
References
https://jira.xwiki.org/browse/XWIKI-22030 https://github.com/xwiki/xwiki-platform/commit/40e1afe001d61eafdf13f3621b4b597a0e58a3e3
Impact
In getdocument.vm ; the ordering of the returned documents is defined from an unsanitized request parameter (request.sort) and can allow any user to inject HQL.
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.
It's possible to employ database backend dependent techniques of breaking out of HQL query context, described, for example, here: https://www.sonarsource.com/blog/exploiting-hibernate-injections.
Patches
This has been patched in 13.10.5 and 14.3-rc-1.
Workarounds
There is no known workaround, other than upgrading XWiki.
References
https://jira.xwiki.org/browse/XWIKI-17568
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
Impact On instances where Extension Repository Application is installed, any user can execute any code requiring programming rights on the server. In order to reproduce on an instance, as a normal user without script nor programming rights, go to your profile and add an object of type ExtensionCode.ExtensionClass. Set the description to {{async}}{{groovy}}println("Hello from Description"){{/groovy}}{{/async}} and press Save and View. If the description displays as Hello from Description without any error, then the instance is vulnerable.
Patches This vulnerability has been fixed in XWiki 15.10.9 and 16.3.0.
Workarounds Since Extension Repository Application is not mandatory, it can be safely disabled on instances that do not use it. It is also possible to manually apply this patch to the page ExtensionCode.ExtensionSheet, as well as this patch to the page ExtensionCode.ExtensionAuthorsDisplayer.
References https://jira.xwiki.org/browse/XWIKI-21890 https://github.com/xwiki/xwiki-platform/commit/8659f17d500522bf33595e402391592a35a162e8
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
macro-pdfviewer is a PDF Viewer Macro for XWiki using Mozilla pdf.js. The width parameter of the PDF viewer macro isn't properly escaped, allowing XSS for any user who can edit a page. XSS can impact the confidentiality, integrity and availability of the whole XWiki installation when an admin visits the page with the malicious code. This is fixed in 2.5.6.