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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact When an attacker without script or programming right creates an XClass definition in XWiki (requires edit right), and that same document is later edited by a user with script, admin, or programming right, malicious code could be executed with the rights of the editing user without prior warning. In particular, this concerns custom display code, the script of computed properties and queries in database list properties. Note that warnings before editing documents with dangerous properties have only been introduced in XWiki 15.9, before that version, this was a known issue and the advice was simply to be careful. Patches This has been patched in XWiki 16.10.2, 16.4.7 and 15.10.16 by adding an analysis for the respective XClass properties. Workarounds We're not aware of any real workarounds apart from just being careful with editing documents previously edited by untrusted users as a user with script, admin or programming right.
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 When editing content that contains "dangerous" macros like malicious script macros that were authored by a user with fewer rights, XWiki warns about the execution of these macros since XWiki 15.9RC1. These required rights analyzers that trigger these warnings are incomplete, allowing an attacker to hide malicious content. For most macros, the existing analyzers don't consider non-lowercase parameters. Further, most macro parameters that can contain XWiki syntax like titles of information boxes weren't analyzed at all. Similarly, the "source" parameters of the content and context macro weren't anylzed even though they could contain arbitrary XWiki syntax. In the worst case, this could allow a malicious to add malicious script macros including Groovy or Python macros to a page that are then executed after another user with programming righs edits the page, thus allowing remote code execution. Patches The required rights analyzers have been made more robust and extended to cover…
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 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…
Recommended action: Upgrade to 16.2.0 or 15.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.