#maven

### Impact An attacker can create a template provider on any document that is part of the wiki (could be the attacker's user profile) that contains malicious code. This code is executed when this template provider is selected during document creation which can be triggered by sending the user to a URL. For the attacker, the only requirement is to have an account as by default the own user profile is editable. This allows an attacker to execute arbitrary actions with the rights of the user opening the malicious link. Depending on the rights of the user, this may allow remote code execution and full read and write access to the whole XWiki installation. For reproduction, the following steps can be used: 1. As a simple user with no script right, edit the user profile with the object editor and add an object of type "Template Provider Class". Set the name to "My Template", set template to any page on the wiki. In "Creation Restrictions", enter `<img onerror="alert(1)" src="https://www.ex...

### Impact The footnote macro executed its content in a potentially different context than the one in which it was defined. In particular in combination with the include macro, this allows privilege escalation from a simple user account in XWiki to programming rights and thus remote code execution, impacting the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, perform the following steps: 1. Edit your user profile with the object editor and add an object of type DocumentSheetBinding with value XWiki.ClassSheet 2. Edit your user profile with the wiki editor and add the syntax `{{footnote}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/footnote}}` When the text "Hello from groovy!" is displayed at the bottom of the document, the installation is vulnerable. Instead, an error should be displayed. ### Patches This vulnerability has been patched in XWiki 14.10.6 and 15.1-rc-1. ### Workarounds There is no workaround apart from upgradi...

### Impact When a document has been deleted and re-created, it is possible for users with view right on the re-created document but not on the deleted document to view the contents of the deleted document. Such a situation might arise when rights were added to the deleted document. This can be exploited through the diff feature and, partially, through the REST API by using versions such as `deleted:1` (where the number counts the deletions in the wiki and is thus guessable). Given sufficient rights, the attacker can also re-create the deleted document, thus extending the scope to any deleted document as long as the attacker has edit right in the location of the deleted document. ### Patches This vulnerability has been patched in XWiki 14.10.8 and 15.3 RC1 by properly checking rights when deleted revisions of a document are accessed. ### Workarounds The only workaround is to regularly [clean deleted documents](https://extensions.xwiki.org/xwiki/bin/view/Extension/Index%20Application#...

### Impact An attacker with edit access on any document (can be the user profile which is editable by default) can move any attachment of any other document to this attacker-controlled document. This allows the attacker to access and possibly publish any attachment of which the name is known, regardless if the attacker has view or edit rights on the source document of this attachment. Further, the attachment is deleted from the source document. This vulnerability exists since the introduction of attachment move support in XWiki 14.0 RC1. ### Patches This vulnerability has been patched in XWiki 14.4.8, 14.10.4, and 15.0 RC1. ### Workarounds There is no workaround apart from upgrading to a fixed version. ### References * https://jira.xwiki.org/browse/XWIKI-20334 * https://github.com/xwiki/xwiki-platform/commit/d7720219d60d7201c696c3196c9d4a86d0881325 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://ji...

### 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. This can be reproduced with the following steps: 1. As an advanced user, use the object editor to add an object of type `UIExtensionClass` to your user profile. Set the value "Extension Point ID" to `{{/html}}{{async async=false cache=false}}{{groovy}}println("Hello from Groovy!"){{/groovy}}{{/async}}` 2. Open `<xwiki-host>/xwiki/bin/edit/XWiki/<username>?sheet=Menu.UIExtensionSheet` where `<xwiki-host>` is the URL of your XWiki installation and `<username>` is your user name. If the text `Hello from Groovy!" selected="selected">` is displayed in the output, the attack succeeded. ### Patches This has been patched in XWiki 14.10.8 and 15.3 RC1 by adding proper escaping. ### Workarounds The [patch](https://github.com/xwiki/xwiki-platform/commit/9e8f080094333de...

Jenkins Multibranch Scan Webhook Trigger Plugin 1.0.9 and earlier uses a non-constant time comparison function when checking whether the provided and expected webhook token are equal, potentially allowing attackers to use statistical methods to obtain a valid webhook token.

XWiki Rendering is a generic Rendering system that converts textual input in a given syntax into another syntax. The cleaning of attributes during XHTML rendering, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid attribute names. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki. When a user moves the mouse over a malicious link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. While this attribute was correctly recognized as not allowed, the attribute was still printed with a prefix `data-xwiki-translated-attribute-` without further cleaning or validation. This problem has been patched in XWiki 14.10.4 and 15.0 RC1 by ...

The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. `maxBodyLebgth` was not used when receiving Message objects. Attackers could send a very large Message causing a memory overflow and triggering an OOM Error. Users of RabbitMQ may suffer from DoS attacks from RabbitMQ Java client which will ultimately exhaust the memory of the consumer. This vulnerability was patched in version 5.18.0.

By Owais Sultan Looking for a SaaS SEO consultant? We’ve rounded up the top 15 SaaS SEO experts you need to… This is a post from HackRead.com Read the original post: 15 Best SaaS SEO Experts That Will Help You Dominate Online

### Impact Given specially crafted zip or JAR file, `IO.unzip` allows writing of arbitrary file. The follow is an example of a malicious entry: ``` +2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys ``` This would have a potential to overwrite `/root/.ssh/authorized_keys`. Within sbt's main code, `IO.unzip` is used in `pullRemoteCache` task and `Resolvers.remote`; however many projects use `IO.unzip(...)` directly to implement custom tasks - https://github.com/search?q=IO.unzip+language%3AScala&type=code&l=Scala&p=1 ### Patches The problem has been patched in https://github.com/sbt/io/pull/360 sbt 1.9.7 is available with the fix. ### Workarounds A workaround might be use some other library to unzip. ### References - https://github.com/snyk/zip-slip-vulnerability - https://security.snyk.io/vuln/SNYK-JAVA-ORGCODEHAUSPLEXUS-31680 - https://github.com/sbt/io/issues/358