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
The PlantUML Macro is vulnerable to Server-Side Request Forgery (SSRF). The macro allows users to specify an alternative PlantUML server via the server parameter. However, the application does not validate the supplied URL. An attacker can supply an internal IP address or a malicious external URL. The XWiki server will attempt to connect to this URL to "render" the diagram.
This issue affects all versions of the Plant UML Macro extension till version 2.4 included.
Patches
Version 2.4.1 of the Plant UML Macro extension fixes the issue by verifying if the supplied server domain matches one of the trusted domain configured inside of XWiki.
Workarounds
Protect the XWiki server by placing it in a DMZ so that it cannot access any other internal servers.
Resources
The issue was fixed in PLANTUML-25 by the commit c8b19bda93058794e04c8862fc7ca85c59b5fe5c.
For more information
If there are any questions or comments about this advisory: Open an issue in JIRA XWiki.org Send an email to Security Mailing List
Attribution
The issue was reported by Łukasz Rybak.
CryptPad 2025.3.1 allows unbounded WebSocket frame flood. A remote, unauthenticated attacker can significantly degrade or deny service for all users of a CryptPad instance. Fixed in 2026.2.2.
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.
Impact A reflected cross-site scripting vulnerability (XSS) in the compare view between revisions of a page allows executing JavaScript code in the user's browser. If the current user is an admin, this can not only affect the current user but also the confidentiality, integrity and availability of the whole XWiki instance.
Patches The problem has been patched by properly escaping the URL parameters.
Workarounds The patch can be applied manually to templates/changesdoc.vm in the deployed WAR.
Attribution
XWiki thanks Mike Cole @mikecole-mg for discovering and reporting this vulnerability.
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.
Impact
The Blog Application is vulnerable to Stored Cross-Site Scripting (XSS) via the Blog Post Title. The vulnerability arises because the post title is injected directly into the HTML <title> tag without proper escaping.
An attacker with permissions to create or edit blog posts can inject malicious JavaScript into the title field. This script will execute in the browser of any user (including administrators) who views the blog post. This leads to potential session hijacking or privilege escalation.
To reproduce:
Log in as a user with rights to create blog posts. Create a new blog post. In the Title field, insert the following payload designed to break out of the title tag: </title><script>alert('XSS in title blog')</script> Save (Publish) the post. View the post in the blog home page
Patches The vulnerability has been patched in the blog application version 9.15.7 by adding missing escaping.
Workarounds XWiki Blog Application maintainers are not aware of any workarounds.
Resources https://jira.xwiki.org/browse/BLOG-245 https://github.com/xwiki-contrib/application-blog/commit/cca87f0a0edc2e7e049d46d51f4a4d8f78b714ba
Attribution
Łukasz Rybak reported this vulnerability.
Impact
It's possible using comments to inject CSS that would transform the full wiki in a link area leading to a malicious page. All versions of XWiki are impacted by this kind of attack.
Patches
The problem has been patched not by preventing injecting CSS in comments, which is currently a feature of XWiki, but by requiring confirmation from users when driving them to untrusted domains after clicking on a link, thus preventing any click-jacking attack. This security measure has been put in place in XWiki 17.9.0, 17.4.6, 16.10.13.
Workarounds
There's no out-of-the-box workaround, but it should be possible to partly reuse the javascript code provided for the security measure in a JSX object inside the wiki, to request the same kind of confirmation.
References JIRA ticket: https://jira.xwiki.org/browse/XWIKI-23433 Documentation of the new security measure: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/17.9.0RC1/Entry006/ Commit for the security fix: https://github.com/xwiki/xwiki-platform/commit/29cb81f3a5387cf822d7e7534bdd63903275f86b
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
Thanks Tomas Keech (Sentrium Security Ltd) for reporting this vulnerability.
Impact A reflected cross site scripting (XSS) vulnerability in XWiki allows an attacker to execute arbitrary actions in XWiki with the rights of the victim if the attacker manages to trick a victim into visiting a crafted URL. If the victim has administrative or programming rights, those rights can be exploited to gain full access to the XWiki installation.
Patches This vulnerability has been patched in XWiki 17.8.0RC1, 17.4.5 and 16.10.12.
Workarounds The patch can be applied manually, only a single line in templates/loggingmacros.vm needs to be changed, no restart is required.
References https://github.com/xwiki/xwiki-platform/commit/8337ac8c3b19c37f306723b638b2cae8b0a57dbf https://jira.xwiki.org/browse/XWIKI-23462
Attribution
We thank Mike Cole @mikecole-mg for discovering and reporting this vulnerability.
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 Anyone who has view rights on the Calendar.JSONService page, including guest users can exploit this vulnerability by accessing database info, with the exception of passwords.
Workarounds Remove the Calendar.JSONService page. This will however break some functionalities.
References
Jira issue: FULLCAL-82: Calendar.JSONService exposes emails of all users
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 who can edit their own user profile or any other document 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 reason is that rendering output is included as content of HTML macros with insufficient escaping, and it is thus possible to close the HTML macro and inject script macros that are executed with programming rights. To demonstrate, the content {{html}}{{/html {{/html}}}} can be inserted into any field of the user profile that supports wiki syntax like the "About" field. If this leads to the display of raw HTML, the instance is vulnerable.
Patches This problem has been patched by extending the escaping introduced by XRENDERING-693 to also cover closing HTML macros that have spaces after the macro name in XWiki 16.10.10, 17.4.3 and 17.6.0RC1. A similar fix has been applied in org.xwiki.platform:xwiki-platform-oldcore as an extra safety net, see XWIKI-23378. At this point, we're not aware that this extra safety net would be required for security.
The patch also fixes the injection of opening HTML macro syntaxes, e.g., with {{html}}{{html{{/html}}}} which disrupts the rendering of the user profile but for which we haven't found any further security impact apart from the disruption of the UI.
Workarounds We're not aware of any workarounds except for upgrading the affected module to a version with a fix.
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.
Impact A reflected XSS vulnerability in XWiki allows an attacker to send a victim to a URL with a deletion confirmation message on which the attacker-supplied script is executed when the victim clicks the "No" button. When the victim has admin or programming right, this allows the attacker to execute basically arbitrary actions on the XWiki installation including remote code execution.
Patches This vulnerability has been patched in XWiki 16.10.10, 17.4.2 and 17.5.0 by using the affected URL parameter only in the intended context.
Workarounds The patch can be manually applied to the templates that are present in the WAR. A restart of XWiki is needed for the changes to be applied.
XWiki Remote Macros provides XWiki rendering macros that are useful when migrating content from Confluence. Prior to 1.27.1, the macro executes Velocity from the details pages without checking for permissions, which can lead to remote code execution. This vulnerability is fixed in 1.27.1.
Impact
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, like http://myhots/webapps/xwiki/WEB-INF/xwiki.cfg, http://myhots/webapps/xwiki/WEB-INF/xwiki.properties or http://myhots/webapps/xwiki/WEB-INF/hibernate.cfg.xml.
Patches
This has been patched in 16.10.11, 17.4.4, 17.7.0.
Workarounds
The workaround is to modify the startxwiki.sh script following https://github.com/xwiki/xwiki-platform/compare/8b68d8a70b43f25391b3ee48477d7eb71b95cf4b...99a04a0e2143583f5154a43e02174155da7e8e10.
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
Vulnerability reported by Joseph Huber.
Summary A user with no view rights on a page may see the content of an office attachment displayed with the view file macro.
Details If on a public page is displayed an office attachment from a restricted page, a user with no view rights on the restricted page can view the attachment content, no matter the display type used.
PoC 1. Install and activate the Pro Macros application 2. Create a page and limit the view rights for a test user 3. Add an attachment to the restricted page 4. Create a new public page 5. Add the view file macro and select the attachment from the restricted page using any display type 6. Login as the test user with restricted view rights 7. The user will see the content despite having no view rights
Workarounds None
Impact Private data can be leaked if a user knows the reference to an attachment and has edit rights on a page.
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
The PDF export uses a background job that runs on the server-side. Jobs like this have a status that is serialized in the permanent directory when the job is finished. The job status includes the job request. The PDF export job request is initialized, before the job starts, with some context information that is needed to replicate the HTTP request (used to trigger the export) in the background thread used to run the export job. This context information includes the cookies from the HTTP request that triggered the export. As a result, the user cookies (including the encrypted username and password) are stored in the permanent directory after the PDF export is finished. As the encryption key is stored in the same data directory (by default it is generated in data/configuration.properties), this means that this job status contains the equivalent of the plain text password of the user who requested the PDF export.
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.
Patches
This vulnerability has been patched in XWiki 16.4.8, 16.10.7 and 17.4.0RC1.
Workarounds
We're not aware of any workarounds except for upgrading.
XWiki through version 17.3.0 is affected by multiple stored Cross-Site Scripting (XSS) vulnerabilities in the Administration interface, specifically under the Presentation section of the Global Preferences panel. An authenticated administrator can inject arbitrary JavaScript payloads into the HTTP Meta Info, Footer Copyright, and Footer Version fields. These inputs are stored and subsequently rendered without proper output encoding or sanitization on public-facing pages. As a result, the injected scripts are persistently executed in the browser context of any visitor to the affected instances including both authenticated and unauthenticated users. No user interaction is required beyond visiting a page that includes the malicious content. Successful exploitation can lead to session hijacking, credential theft, unauthorized actions via session riding, or further compromise of the application through client-side attacks. The vulnerability introduces significant risk in any deployment, especially in shared or internet-facing environments where administrator credentials may be compromised.
XWiki through version 17.3.0 is vulnerable to Server-Side Template Injection (SSTI) in the Administration interface, specifically within the HTTP Meta Info field of the Global Preferences Presentation section. An authenticated administrator can inject crafted Apache Velocity template code, which is rendered on the server side without proper validation or sandboxing. This enables the execution of arbitrary template logic, which may expose internal server information or, in specific configurations, lead to further exploitation such as remote code execution or sensitive data leakage. The vulnerability resides in improper handling of dynamic template rendering within user-supplied configuration fields.