#java

Concrete CMS versions 9.0.0 through 9.3.2 are affected by a stored XSS vulnerability in the generate dashboard board instance functionality. The Name input field does not check the input sufficiently letting a rogue administrator hav the capability to inject malicious JavaScript code. The Concrete CMS security team gave this vulnerability a CVSS v3.1 score of 3.1 with a vector of AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator and a CVSS v4 score of 1.8 with a vector of CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N Thanks fhAnso for reporting.

Ubuntu Security Notice 6936-1 - It was discovered that Apache Commons Collections allowed serialization support for unsafe classes by default. A remote attacker could possibly use this issue to execute arbitrary code.

In this first Deep Dive with NTDR, we explore how defenders can leverage Snort for the detection of evasive malware threats.

DEV#POPPER is back, looking to deliver a comprehensive, updated infostealer to coding job seekers by way of a savvy social engineering gambit.

### Impact ZITADEL uses HTML for emails and renders certain information such as usernames dynamically. That information can be entered by users or administrators. Due to a missing output sanitization, these emails could include malicious code. This may potentially lead to a threat where an attacker, without privileges, could send out altered notifications that are part of the registration processes. An attacker could create a malicious link, where the injected code would be rendered as part of the email. During investigation of this issue a related issue was found and mitigated, where on the user's detail page the username was not sanitized and would also render HTML, giving an attacker the same vulnerability. While it was possible to inject HTML including javascript, the execution of such scripts would be prevented by most email clients and the Content Security Policy in Console UI. ### Patches 2.x versions are fixed on >= [2.58.1](https://github.com/zitadel/zitadel/releases/tag/...

### Impact Tokens with third-party blocks containing trusted annotations generated through a third party block request. Due to implementation issues in biscuit-java, third party block support in published versions is inoperating. Nevertheless, to synchronize with other implementations, we publish this advisory and the related fix. ### Description Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it: the public key of the previous block (used in the signature) the public keys part of the token symbol table (for public key interning in datalog expressions) A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair. Consider the following example (nominal case) * Authority A emits the following token: `check if thirdparty("b")...

### Impact By creating a conflict when another user with more rights is currently editing a page, it is possible to execute JavaScript snippets on the side of the other user, which compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on a XWiki instance, a user with admin rights needs to edit a document without saving right away. Then, as another user without any other right than edit on the specific document, change the whole content to `<script>alert('XSS')</script>`. When the admin user then saves the document, a conflict popup appears. If they select "Fix each conflict individually" and see an alert displaying "XSS", then the instance is vulnerable. ### Patches This has been patched in XWiki 15.10.8 and 16.3.0RC1. ### Workarounds We're not aware of any workaround except upgrading. ### References * https://jira.xwiki.org/browse/XWIKI-21626 * https://github.com/xwiki/xwiki-platform/commit/821d43ec45e67d45a6735a0717b9b77fffc...

A binary in Apple macOS could allow an adversary to execute an arbitrary binary that bypasses SIP.

### Impact Any user with edit right on any page can perform arbitrary remote code execution by adding instances of `XWiki.SearchSuggestConfig` and `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.SearchSuggestConfig` to your profile page, and an object of type `XWiki.SearchSuggestSourceClass` as well. On this last object, set both `name` and `icon` properties to `$services.logging.getLogger("attacker").error("I got programming: $services.security.authorization.hasAccess('programming')")` and `limit` and `engine` to `{{/html}}{{async}}{{velocity}}$services.logging.getLogger("attacker").error("I got programming: $services.security.authorization.hasAccess('programming')"){{/velocity}}{{/async}}`. Save and display the page. If the logs contain any message `ERROR ...

### Impact When uploading an attachment with a malicious filename, malicious JavaScript code could be executed. This requires a social engineering attack to get the victim into uploading a file with a malicious name. The malicious code is solely executed during the upload and affects only the user uploading the attachment. While this allows performing actions in the name of that user, it seems unlikely that a user wouldn't notice the malicious filename while uploading the attachment. In order to reproduce, as any user, create a file named `"><img src=1 onerror=alert(1)>.jpg`. Then go to any page where you have edit rights and upload the file in the attachments tab. If alerts appear and display "1", then the instance is vulnerable. ### Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0. ### Workarounds We're not aware of any workaround except upgrading. ### References * https://jira.xwiki.org/browse/XWIKI-19611 * https://jira.xwiki.org/browse/XWIKI-21769 * h...