ghsa

### 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 ...

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+.

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.

### 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...

### Impact The "restricted" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1 and massively improved in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid HTML comments. As a consequence, any code relying on this "restricted" mode for security is vulnerable to JavaScript injection ("cross-site scripting"/XSS). An example are anonymous comments in XWiki where the HTML macro filters HTML using restricted mode: ```html {{html}} <!--> <Details Open OnToggle=confirm("XSS")> {{/html}} ``` When a privileged user with programming rights visits such a comment in XWiki, the malicious JavaScript code is executed in the context of the user session. This allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. Note that while all versions since 4.2-milestone-1 should be vulnerable, only starting with version 14.6-rc-1 the HTML comment is...

### Impact The gatsby-plugin-sharp plugin prior to versions 5.8.1 and 4.25.1 contains a path traversal vulnerability exposed when running the Gatsby develop server (`gatsby develop`). The following steps can be used to reproduce the vulnerability: ``` # Create a new Gatsby project, and install gatsby-plugin-sharp $ npm init gatsby $ cd my-gatsby-site $ npm install gatsby-plugin-sharp # Add the plugin to gatsby-config.js module.exports = { plugins: [ { resolve: `gatsby-plugin-sharp`, }, ] } # Start the Gatsby develop server $ gatsby develop # Execute the path traversal vulnerability $ curl "http://127.0.0.1:8000/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd" ``` It should be noted that by default `gatsby develop` is only accessible via the localhost `127.0.0.1`, and one would need to intentionally expose the server to other interfaces to exploit this vulnerability by using server options such as `--host 0.0.0.0`,...

On version 3.0.0 through 3.1.1, Apache DolphinScheduler's python gateway suffered from improper authentication: an attacker could use a socket bytes attack without authentication. This issue has been fixed from version 3.1.2 onwards. For users who use version 3.0.0 to 3.1.1, you can turn off the python-gateway function by changing the value `python-gateway.enabled=false` in configuration file `application.yaml`. If you are using the python gateway, please upgrade to version 3.1.2 or above.