ghsa

Shopware v5.5.10 was discovered to contain a cross-site scripting (XSS) vulnerability.

In modoboa prior to 2.1.0, sending a GET request to the endpoint `/api/v2/parameters/core/` returns sensitive information without any authentication or authorization.

modoboa prior to 2.1.0 is vulnerable to cross-site request forgery. An attacker must be logged in as admin to exploit this issue.

sidekiq prior to 7.0.8 is vulnerable to reflected cross-site scripting.

RosarioSIS prior to version 10.9.3 has a vulnerability that allows a user to return to a page containing personally identifiable information (PII) and sensitive information even after logging out of the application by using the browser's back button.

### Impact Steps to reproduce: Open <xwiki-host>/xwiki/bin/view/XWiki/Notifications/Code/LegacyNotificationAdministration?since=%7B%7B%2Fhtml%7D%7D+%7B%7Basync+async%3D%22true%22+cached%3D%22false%22+context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello+%22+%2B+%22from+groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D, where <xwiki-host> is the URL of your XWiki installation. This demonstrates an XWiki syntax injection attack via the since-parameter, allowing privilege escalation from view to programming rights. ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8 and 14.10.3. ### Workarounds For versions >= 14.6-rc-1 the workaround is to modify the page `XWiki.Notifications.Code.LegacyNotificationAdministration` to add the missing escaping, as described on https://github.com/xwiki/xwiki-platform/commit/8e7c7f90f2ddaf067cb5b83b181af41513028754#diff-4e13f4ee4a42938bf1201b7ee71ca32edeacba22559daf0bcb89d534e0225949R70 For vers...

### Impact Steps to reproduce: 1. As a user without script or programming right, edit your user profile (or any other document) with the wiki editor and add the content `{{groovy}}println("Hello " + "from Groovy!"){{/groovy}}` 1. Edit the document with the object editor and add an object of type AppWithinMinutes.LiveTableClass (no values need to be set, just save) 1. View the document ### Patches The vulnerability has been patched in XWiki 15.0-rc-1 and 14.10.3. ### Workarounds There is no known workaround. ### References https://jira.xwiki.org/browse/XWIKI-20423 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:[email protected])

### Impact It's possible to display any page you cannot access through the combination of the async and display macro. Steps to reproduce: 1. Enable comments for guests by giving guests comment rights 2. As a guest, create a comment with content ```{{async}}{{display reference="Menu.WebHome" /}}{{/async}}``` 3. Open the comments viewer from the menu (appends ?viewer=comments to the URL) -> the `Menu.WebHome` is displayed while the expectation would be to have an error that the current user is not allowed to see it ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8, and 13.10.11. ### Workarounds There is no known workaround. ### References https://jira.xwiki.org/browse/XWIKI-20394 https://jira.xwiki.org/browse/XRENDERING-694 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:[email protected])

### Impact It's possible to execute anything with the right of the Scheduler Application sheet page. To reproduce: 1. As a user without script or programming rights, edit your user profile with the object editor and add a new object of type XWiki.SchedulerJobClass (search for "Scheduler") 1. In "Job Script", add the following ```{{/code}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy} {{/async}}``` 1. Click "Save & View" 1. If the job information isn't already displayed (you should see "Job Name", "Job Description", etc.), append ?sheet=XWiki.SchedulerJobSheet to the URL. ### Patches This has been patched in XWiki 14.10.3 and 15.0 RC1. ### Workarounds While the fix in the scheduler itself is easy, it relies on the code macro `source` parameter, which was introduced in 14.10.2 so you have to upgrade to benefit from it. ### References https://jira.xwiki.org/browse/XWIKI-20295 https://jira.xwiki.org/browse/XWIK...

### Impact Any user who can edit their own user profile can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. The following syntax, to be put, e.g., in the about section of the user profile, demonstrates a proof of concept: ``` {{html wiki="true"}}~{~{~/~h~t~m~l~}~}~ ~{~{~c~a~c~h~e~}~}~{~{~g~r~o~o~v~y~}~}~p~r~i~n~t~l~n~(~1~)~{~{~/~g~r~o~o~v~y~}~}~{~{~/~c~a~c~h~e~}~}~{{/html}} ``` While it would be expected that the above code is displayed just without the `~`, in fact just "1" is displayed, followed by a lot of raw HTML code. The same vulnerability can also be exploited in other contexts where the `display` method on a document is used to display a field with wiki syntax, for example in applications created using [App Within Minutes](https://extensions.xwiki.org/xwiki/bin/view/Extension/App%20Within%20Minutes%20Application). ### Patches This has been patched in XWiki...