#maven

Keycloak allows arbitrary URLs as SAML Assertion Consumer Service POST Binding URL (ACS), including JavaScript URIs (javascript:). Allowing JavaScript URIs in combination with HTML forms leads to JavaScript evaluation in the context of the embedding origin on form submission. #### Acknowledgements: Special thanks to Lauritz Holtmann for reporting this issue and helping us improve our project.

Keycloak does not correctly validate its client step-up authentication. A password-authed attacker could use this flaw to register a false second auth factor, alongside the existing one, to a targeted account. The second factor then permits step-up authentication.

An issue was found in the redirect_uri validation logic that allows for a bypass of otherwise explicitly allowed hosts.

Versions of the BlazeMeter Jenkins plugin prior to 4.22 contain a flaw which results in credential enumeration.

Ubuntu Security Notice 6730-1 - It was discovered that Apache Maven Shared Utils did not handle double-quoted strings properly, allowing shell injection attacks. This could allow an attacker to run arbitrary code.

Much of the open source code embedded in enterprise software stacks comes from small, under-resourced, volunteer-run projects.

### Impact It is possible to schedule/trigger/unschedule existing jobs by having an admin visit the Job Scheduler page through a predictable URL, for example by embedding such an URL in any content as an image. To reproduce in an XWiki installation, open `<xwiki-host>:/xwiki/bin/view/Scheduler/?do=trigger&which=Scheduler.NotificationEmailDailySender` as a user with admin rights. If there is no error message that indicates the CSRF token is invalid, the installation is vulnerable. ### Patches The vulnerability has been fixed on XWiki 14.10.19, 15.5.5, and 15.9. ### Workarounds Modify the Scheduler.WebHome page following this [patch](https://github.com/xwiki/xwiki-platform/commit/f16ca4ef1513f84ce2e685d4a05d689bd3a2ab4c#diff-1e2995eacccbbbdcc4987ff64f46ac74837d166cf9e92920b4a4f8af0f10bd47). ### References - https://jira.xwiki.org/browse/XWIKI-20851 - https://github.com/xwiki/xwiki-platform/commit/f16ca4ef1513f84ce2e685d4a05d689bd3a2ab4c

### Impact By creating a document with a specially crafted title, it is possible to trigger remote code execution in the (Solr-based) search in XWiki. This allows any user who can edit the title of a space (all users by default) to execute any Groovy code in the XWiki installation which compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, as a user without script nor programming rights, create a document with title `{{/html}}{{async}}{{groovy}}println("Hello from Groovy Title!"){{/groovy}}{{/async}}` and content `Test Document`. Using the search UI, search for `"Test Document"`, then deploy the `Location` facet on the right of the screen, next to the search results. The installation is vulnerable if you see an item such as: ``` Hello from Groovy Title! </a> <div class="itemCount">1</div> </li> </ul> {{/html}} ``` ### Patches This has been patched in XWiki 14.10.20, 15.5.4 and 15.10 RC1. ### Workarounds Modify the `Main.SolrSpaceF...

### Impact In multilingual wikis, translations can be edited by any user who has edit right, circumventing the rights that are normally required for authoring translations (script right for user-scope translations, wiki admin for translations on the wiki). This can be exploited for remote code execution if the translation value is not properly escaped where it is used. To reproduce, in a multilingual wiki, as a user without script or admin right, edit a translation of `AppWithinMinutes.Translations` and in the line `platform.appwithinminutes.description=` add `{{async}}{{groovy}}println("Hello from Translation"){{/groovy}}{{/async}}` at the end. Then open the app with in minutes home page (`AppWithinMinutes.WebHome`) in the same locale. If translations are still working and "Hello from Translation" is displayed at the end of the introduction, the installation is vulnerable. ### Patches This has been patched in XWiki 14.10.20, 15.5.4 and 15.10RC1. ### Workarounds We're not aware of ...

### Impact Remote code execution is possible via PDF export templates. To reproduce on an installation, register a new user account with username `PDFClass` if `XWiki.PDFClass` does not exist. On `XWiki.PDFClass`, use the class editor to add a "style" property of type "TextArea" and content type "Plain Text". Then, add an object of class `PDFClass` and set the "style" attribute to `$services.logging.getLogger('PDFClass').error("I got programming: $services.security.authorization.hasAccess('programming')")`. Finally, go to `<host>/xwiki/bin/export/Main/WebHome?format=pdf&pdftemplate=XWiki.PDFClass`. If the logs contain "ERROR PDFClass - I got programming: true", the instance is vulnerable. ### Patches This vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10-rc-1. ### Workarounds If PDF templates are not typically used on the instance, an administrator can create the document `XWiki.PDFClass` and block its edition, after making sure that it does not contain a `style` att...