#git

### Impact By creating a document with a special crafted documented reference and an `XWiki.SchedulerJobClass` XObject, it is possible to execute arbitrary code on the server whenever an admin visits the scheduler page or the scheduler page is referenced, e.g., via an image in a comment on a page in the wiki. To reproduce on an XWiki installation, click on this link to create a new document : `<xwiki-host>/xwiki/bin/view/%22%3E%5D%5D%7B%7B%2Fhtml%7D%7D%7B%7Basync%20context%3D%22request/parameters%22%7D%7D%7B%7Bvelocity%7D%7D%23evaluate%28%24request/eval%29/`. Then, add to this document an object of type `XWiki.SchedulerJobClass`. Finally, as an admin, go to `<xwiki-host>/xwiki/bin/view/Scheduler/?eval=$services.logging.getLogger(%22attacker%22).error(%22Hello%20from%20URL%20Parameter!%20I%20got%20programming:%20$services.security.authorization.hasAccess(%27programming%27)%22)`. If the logs contain `ERROR attacker - Hello from URL Parameter! I got programming: true`, the installation ...

### 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 XWiki's database search allows remote code execution through the search text. This allows remote code execution for any visitor of a public wiki or user of a closed wiki as the database search is by default accessible for all users. This impacts the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on an instance, without being logged in, go to `<hostname>/xwiki/bin/get/Main/DatabaseSearch?outputSyntax=plain&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello%20from%22%20%2B%20%22%20search%20text%3A%22%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D%20`. If the title of the RSS channel contains `Hello from search text:42`, the instance is vulnerable. ### Patches This vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10RC1. ### Workarounds It is possible to manually apply [this patch](https://github.com/xwiki/xwiki-platform/commit/95bdd6cc6298acdf7f8f21298d40eeb839...

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

### Impact Any user with edit right on any page can execute any code on the server by adding an object of type `XWiki.SearchSuggestSourceClass` to their user profile or any other page. This compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on an instance, as a user without script nor programming rights, add an object of type `XWiki.SearchSuggestSourceClass` to your profile page. On this object, set every possible property to `}}}{{async}}{{groovy}}println("Hello from Groovy!"){{/groovy}}{{/async}}` (i.e., name, engine, service, query, limit and icon). Save and display the page, then append `?sheet=XWiki.SearchSuggestSourceSheet` to the URL. If any property displays as `Hello from Groovy!}}}`, then the instance is vulnerable. ### Patches This vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10 RC1. ### Workarounds [This patch](https://github.com/xwiki/xwiki-platform/commit/6a7f19f6424036fce3d703413137adde950ae809#...

### Impact It is possible to access the hash of a password by using the diff feature of the history whenever the object storing the password is deleted. Using that vulnerability it's possible for an attacker to have access to the hash password of a user if they have rights to edit the users' page. Now with the default right scheme in XWiki this vulnerability is normally prevented on user profiles, except by users with Admin rights. Note that this vulnerability also impacts any extensions that might use passwords stored in xobjects: for those usecases it depends on the right of those pages. There is currently no way to be 100% sure that this vulnerability has been exploited, as an attacker with enough privilege could have deleted the revision where the xobject was deleted after rolling-back the deletion. But again, this operation requires high privileges on the target page (Admin right). A page with a user password xobject which have in its history a revision where the object has be...

### Summary The [patch that addressed CVE-2023-40581](https://github.com/yt-dlp/yt-dlp/commit/de015e930747165dbb8fcd360f8775fd973b7d6e) attempted to prevent RCE when using `--exec` with `%q` by replacing double quotes with two double quotes. However, this escaping is not sufficient, and still allows expansion of environment variables. Support for output template expansion in `--exec`, along with this vulnerable behavior, was added to `yt-dlp` in version [2021.04.11](https://github.com/yt-dlp/yt-dlp/releases/tag/2021.04.11). ```cmd > yt-dlp "https://youtu.be/42xO6rVqf2E" --ignore-config -f 18 --exec "echo %(title)q" [youtube] Extracting URL: https://youtu.be/42xO6rVqf2E [youtube] 42xO6rVqf2E: Downloading webpage [youtube] 42xO6rVqf2E: Downloading ios player API JSON [youtube] 42xO6rVqf2E: Downloading android player API JSON [youtube] 42xO6rVqf2E: Downloading m3u8 information [info] 42xO6rVqf2E: Downloading 1 format(s): 18 [download] Destination: %CMDCMDLINE：~-1%&echo pwned&calc.exe [4...

By cybernewswire Dubai, UAE, April 10th, 2024, CyberNewsWire Match Systems, a leading authority in crypto crimes investigations and crypto AML… This is a post from HackRead.com Read the original post: Match Systems publishes report on the consequences of CBDC implementation, led by CEO Andrei Kutin