#mac

InCopy versions 18.1 (and earlier), 17.4 (and earlier) are affected by a Use After Free vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Adobe Substance 3D Stager version 2.0.1 (and earlier) is affected by an out-of-bounds read vulnerability that could lead to disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Usually focused on going after cryptocurrency organizations, the threat actor has begun targeting defense companies around the world.

Adobe Acrobat Reader versions 23.001.20093 (and earlier) and 20.005.30441 (and earlier) are affected by an out-of-bounds read vulnerability when parsing a crafted file, which could result in a read past the end of an allocated memory structure. An attacker could leverage this vulnerability to execute code in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

### Impact The [Livetable Macro](https://extensions.xwiki.org/xwiki/bin/view/Extension/Livetable%20Macro) wasn't properly sanitizing column names, thus allowing the insertion of raw HTML code including JavaScript. This vulnerability was also exploitable via the [Documents Macro](https://extensions.xwiki.org/xwiki/bin/view/Extension/Documents%20Macro) that is included since XWiki 3.5M1 and doesn't require script rights, this can be demonstrated with the syntax `{{documents id="example" count="5" actions="false" columns="doc.title, before<script>alert(1)</script>after"/}}`. Therefore, this can also be exploited by users without script right and in comments. With the interaction of a user with more rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content. ### Patches This has been patched in XWiki 14.9, 14.4.6, and 13.10.10. ### Workarounds It is possible to apply the...

### Impact The HTML macro does not systematically perform a proper neutralization of script-related html tags. As a result, any user able to use the html macro in XWiki, is able to introduce an XSS attack. This can be particularly dangerous since in a standard wiki, any user is able to use the html macro directly in their own user profile page. ### Patches The problem has been patched in XWiki 14.8RC1. The patch involve that the HTML macro are systematically cleaned up whenever the user does not have script right. ### Workarounds There's no workaround for this issue. ### References * https://jira.xwiki.org/browse/XWIKI-18568 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira](https://jira.xwiki.org) * Email us at [security ML](mailto:[email protected])

### Impact The [RSS macro](https://extensions.xwiki.org/xwiki/bin/view/Extension/RSS%20Macro) that is bundled in XWiki included the content of the feed items without any cleaning in the HTML output when the parameter `content` was set to `true`. This allowed arbitrary HTML and in particular also JavaScript injection and thus cross-site scripting (XSS) by specifying an RSS feed with malicious content. With the interaction of a user with programming rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content and sabotaging the wiki. The issue can be reproduced by inserting the following XWiki syntax in any wiki page like the user account: ``` {{rss feed="https://xssrss.blogspot.com/feeds/posts/default?alt=rss" content="true" /}} ``` If an alert is displayed when viewing the page, the wiki is vulnerable. ### Patches The issue has been patched in XWiki 14.6 RC1, the con...

### Impact The "restricted" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1, only escaped `<script>` and `<style>`-tags but neither attributes that can be used to inject scripts nor other dangerous HTML tags like `<iframe>`. 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}} <a href='' onclick='alert(1)'>XSS</a> {{/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. ### Patches This problem has been patched in XWiki 14.6 RC1 with the introduction of a filter with allowed HTML elements and attributes th...

### Impact Any user with the right to add an object on a 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 styles properties `FlamingoThemesCode.WebHome`. This page is installed by default. #### Reproduction Steps **Steps to reproduce**: - As a user without script or programming rights, edit your user profile with the object editor (enable advanced mode if necessary to get access) and add an object of type "Theme Class" of "FlamingoThemesCode". In the field "body-bg" (all other fields should work, too) add the following text: `{{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}}` - Click "Save & View" - Open <xwiki-host>/xwiki/bin/view/FlamingoThemesCode/WebHomeSheet where <xwiki-host> is the URL of your XWiki installation **Expected result**: The list of color themes either doesn't inc...