ghsa

### Impact Any user who can create a space can become admin of that space through App Within Minutes. The admin right implies the script right and thus allows JavaScript injection. The vulnerability can be exploited by creating an app in App Within Minutes. If the button should be disabled because the user doesn't have global edit right, the app can also be created by directly opening `/xwiki/bin/view/AppWithinMinutes/CreateApplication?wizard=true` on the XWiki installation. ### Patches This has been patched in XWiki 13.10.11, 14.4.8, 14.10.1 and 15.0 RC1 by not granting the space admin right if the user doesn't have script right on the space where the app is created. Error message are displayed to warn the user that the app will be broken in this case. Users who became space admin through this vulnerability won't loose the space admin right due to the fix, so it is advised to check if all users who created AWM apps should keep their space admin rights. ### Workarounds The patch can ...

### Impact Any user with edit rights on any document (e.g., the own user profile) can execute code with programming rights, leading to remote code execution by following these steps: 1. Set the title of any document you can edit (can be the user profile) to ``` {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}} ``` 2. Use the object editor to add an object of type `XWiki.TemplateProviderClass` (named "Template Provider Class") to that document. 3. Go to another document you can view (can be the home page) and append `?sheet=XWiki.AdminTemplatesSheet` to the URL. When the attack is successful, a template with name "Hello from groovy!" is displayed in the list while on fixed systems, the full title should be displayed. ### Patches This vulnerability has been patched in XWiki 13.10.11, 14.4.8, 14.10.1 and 15.0 RC1. ### Workarounds The vulnerability can be fixed by patching the code in the affected XWiki...

### Impact If a guest has view rights on any document, it's possible to create a new user using the `distribution/firstadminuser.wiki` in the wrong context. To reproduce: * On a wiki with view rights for guests but user registration disabled, open as guest <server>/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%2F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7Btemplate+name%3D%22distribution%2Ffirstadminuser.wiki%22+%2F%7D%7D where <server> is the URL of your XWiki installation. * Enter username and password of your choice. * Click "Register and login" ### Patches The vulnerability has been patched in XWiki 15.0-rc-1 and 14.10.1. ### Workarounds There is no known workaround other than upgrading. ### References https://jira.xwiki.org/browse/XWIKI-19852 https://jira.xwiki.org/browse/XWIKI-20400 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwik...

### Impact Any user with edit rights on a page (e.g., it's own user page), can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the information loaded from attachments in `imported.vm`, `importinline.vm`, and `packagelist.vm`. This page is installed by default. Reproduction steps are described in https://jira.xwiki.org/browse/XWIKI-20267 ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11. ### Workarounds The issue can be fixed by applying this [patch](https://github.com/xwiki/xwiki-platform/commit/e4bbdc23fea0be4ef1921d1a58648028ce753344) on `imported.vm`, `importinline.vm`, and `packagelist.vm`. ### References - https://github.com/xwiki/xwiki-platform/commit/e4bbdc23fea0be4ef1921d1a58648028ce753344 - https://jira.xwiki.org/browse/XWIKI-20267 ### For more information If you have any questions or comments about this advisory: * Open ...

pretalx 2.3.1 before 2.3.2 allows path traversal in HTML export (a non-default feature). Organizers can trigger the overwriting (with the standard pretalx 404 page content) of an arbitrary file.

pretalx before 2.3.2 allows path traversal in HTML export (a non-default feature). Users were able to upload crafted HTML documents that trigger the reading of arbitrary files.

In Spring Boot versions 3.0.0 - 3.0.5, 2.7.0 - 2.7.10, and older unsupported versions, an application that is deployed to Cloud Foundry could be susceptible to a security bypass. Users of affected versions should apply the following mitigation: 3.0.x users should upgrade to 3.0.6+. 2.7.x users should upgrade to 2.7.11+. Users of older, unsupported versions should upgrade to 3.0.6+ or 2.7.11+.

### Impact A payments info page of Pay is susceptible to reflected Cross-site scripting. An attacker could create a working URL that renders a javascript link to a user on a Rails application that integrates Pay. This URL could be distributed via email to specifically target certain individuals. If the targeted application contains a functionality to submit user-generated content (such as comments) the attacker could even distribute the URL using that functionality. ### Patches This has been patched in version 6.3.2 and above. Pay will now sanitize the `back` parameter and only permit relative paths.

### Impact In Nunjucks versions prior to version 3.2.4, it was possible to bypass the restrictions which are provided by the autoescape functionality. If there are two user-controlled parameters on the same line used in the views, it was possible to inject cross site scripting payloads using the backslash `\` character. #### Example If the user-controlled parameters were used in the views similar to the following: ``` <script> let testObject = { lang: '{{ lang }}', place: '{{ place }}' }; </script> ``` It is possible to inject XSS payload using the below parameters: ``` https://<application-url>/?lang=jp\&place=};alert(document.domain)// ``` ### Patches The issue was patched in version 3.2.4. ### References - https://bugzilla.mozilla.org/show_bug.cgi?id=1825980

## Description The [CSRF](https://owasp.org/www-community/attacks/csrf) protection enforced by the `@fastify/csrf-protection` library in combination with `@fastify/cookie` can be bypassed from network and same-site attackers under certain conditions. `@fastify/csrf-protection` supports an optional `userInfo` parameter that binds the CSRF token to the user. This parameter has been introduced to prevent cookie-tossing attacks as a fix for [CVE-2021-29624](https://www.cvedetails.com/cve/CVE-2021-29624). Whenever `userInfo` parameter is missing, or its value can be predicted for the target user account, network and [same-site](https://canitakeyoursubdomain.name/) attackers can 1. fixate a `_csrf` cookie in the victim's browser, and 2. forge CSRF tokens that are valid for the victim's session. This allows attackers to bypass the CSRF protection mechanism. As a fix, `@fastify/csrf-protection` starting from version 6.3.0 (and v4.1.0) includes a server-defined secret `hmacKey` that cryptogra...