Privilege escalation (PR) with edit rights through unescaped translations

Steps to reproduce (example):

1. Login with a user with just edit rights on the user profile on a wiki where the help center has been installed with programming rights (most wikis probably).
2. Enable advanced mode
3. Edit the user profile with the wiki editor
4. Enter the content

   help.syntaxtitle={{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}}
   

1. Click "Save & View"
2. Edit the user profile with the object editor
3. Add an object of type "TranslationDocumentClass"
4. Select scope "USER"
5. Click "Save & View"
6. Go to <server>/xwiki/bin/view/XWiki/XWikiSyntax (Or click on the "Help" application and then on "syntax" in the "Page Editing" box).

Expected result:

The content of the syntax guide starts with

{{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}}

Actual result:

The content of the syntax guide starts with "hello from groovy!".

This demonstrates a privilege escalation from a simple user account without any special rights to programming rights. This is due to the interpretation of the translated text as wiki syntax.

I've tried systematically searching for unescaped translations using the following regular expression:

'(^|[^(>]|[^e]>|[^l]e>|[^t]le>|[^i]tle>|[^t]itle>|[^<]title>|(^| )[^$ ]+\()\$services\.localization\.render'

This code tries finding all occurrences of $services.localization.render that aren't preceded with

• "$[^ ]*(" - velocity function invocation, the function hopefully knows how to deal with unescaped parameters.
• "<title>" - title of the page and thus safe.

To keep things fast, these conditions are inverted, I hope I haven't missed anything.

This regular expression matches 228 wiki pages and 218 other files in xwiki-platform. Some of the translations are actually stored in variables that might or might not be escaped later or are in JSX/CSX objects where the result isn't interpreted as wiki syntax and thus aren't exploitable but on manual inspection it seems that in most of the matched wiki pages at least some translations are interpreted as wiki syntax. Further, it might also be that some translations are buried in logic that cannot be triggered as a regular user (as, for example, there is some rights check before the translations are loaded). Other files include velocity templates, JavaScript and CSS files with velocity execution. As most of them aren't interpreted as wiki syntax they aren't directly exploitable, though velocity templates might contain macros that are used in wiki pages and are thus exploitable again. Unescaped translations might also lead to XSS but from my understanding this would require admin rights as this is not interesting for your own user but only for other users and thus XSS through unescaped translations is a much less severe problem. There are also false positives, for example this translations contains Velocity code, but from what I can see it isn't executed, the UI displays the velocity code as-is (which might not be the intended outcome and indicates that there might have been a version of XWiki where it was executed).

I've attached the list of matches in wiki pages and in other files.

It is also difficult to give a concrete affected version as this depends on the individual affected file. Most likely, due to the number of affected files, it won't be possible to create separate issues with exact affects versions and steps to reproduce. I've only added the current version and the help component for now but this certainly affects many more components.

We could also consider disallowing translation for unprivileged users or disallowing translations on the user profile as an additional measure to prevent this kind of privilege escalation globally.