Concrete CMS version 9 prior to 9.2.8 and previous versions prior to 8.5.16 are vulnerable to Stored XSS in the Search Field. Prior to the fix, stored XSS could be executed by an administrator changing a filter to which a rogue administrator had previously added malicious 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:N/I:L/A:L https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator . Thanks Alexey Solovyev for reporting

Concrete CMS version 9 below 9.2.8 and previous versions below 8.5.16 is vulnerable to Stored XSS in blocks of type file. Prior to fix, stored XSS could be caused by a rogue administrator adding malicious code to the link-text field when creating a block of type file. 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:N/I:L/A:L https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator . Thanks Alexey Solovyev for reporting.

Concrete CMS version 9 before 9.2.8 and previous versions before 8.5.16 are vulnerable to Stored XSS in the Custom Class page editing. Prior to the fix, a rogue administrator could insert malicious code in the custom class field due to insufficient validation of administrator provided data. 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:N/I:L/A:L https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator . Thanks Alexey Solovyev for reporting. 

Concrete CMS versions 9 below 9.2.8 and versions below 8.5.16 are vulnerable to Cross-site Scripting (XSS) in the Advanced File Search Filter. Prior to the fix, a rogue administrator could add malicious code in the file manager because of insufficient validation of administrator provided data. All administrators have access to the File Manager and hence could create a search filter with the malicious code attached. 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:N/I:L/A:L https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator .  

Concrete CMS version 9 before 9.2.8 and previous versions prior to 8.5.16 is vulnerable to Stored XSS on the calendar color settings screen since Information input by the user is output without escaping. A rogue administrator could inject malicious javascript into the Calendar Color Settings screen which might be executed when users visit the affected page. The Concrete CMS security team gave this vulnerability a CVSS v3.1 score of 2.0 with a vector of AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N&version=3.1 https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator   Thank you Rikuto Tauchi for reporting

Concrete CMS version 9 before 9.2.7 is vulnerable to Stored XSS via the Name field of a Group type since there is insufficient validation of administrator provided data for that field. A rogue administrator could inject malicious code into the Name field which might be executed when users visit the affected page. The Concrete CMS security team gave this vulnerability a CVSS v3.1 score of 2.2 with a vector of AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N Concrete versions below 9 do not include group types so they are not affected by this vulnerability. Thanks Luca Fuda for reporting.

Concrete CMS before 9.2.3 allows Stored XSS on the Admin Dashboard via /dashboard/system/basics/name. (8.5 and earlier are unaffected.)

Concrete CMS before 8.5.14 and 9 before 9.2.3 allows Cross Site Request Forgery (CSRF) via ccm/calendar/dialogs/event/delete/submit. An attacker can force an admin to delete events on the site because the event ID is numeric and sequential.

Concrete CMS 9 before 9.2.3 is vulnerable to Cross Site Request Forgery (CSRF) at /ccm/system/dialogs/file/delete/1/submit.

Concrete CMS before 8.5.14 and 9 before 9.2.3 is vulnerable to an admin adding a stored XSS payload via the Layout Preset name.

The XWiki licensor application, which manages and enforce application licenses for paid extensions, includes the document `Licenses.Code.LicenseJSON` that provides information for admins regarding active licenses. This document is public and thus exposes this information publicly. The information includes the instance's id as well as first and last name and email of the license owner. This is a leak of information that isn't supposed to be public. The instance id allows associating data on the active installs data with the concrete XWiki instance. Active installs assures that "there's no way to find who's having a given UUID" (referring to the instance id). Further, the information who the license owner is and information about the obtained licenses can be used for targeted phishing attacks. Also, while user information is normally public, email addresses might only be displayed obfuscated, depending on the configuration. This has been fixed in Application Licensing 1.24.2. There are no known workarounds besides upgrading.

Concrete CMS in version 9 before 9.2.5 is vulnerable to reflected XSS via the Image URL Import Feature due to insufficient validation of administrator provided data. A rogue administrator could inject malicious code when importing images, leading to the execution of the malicious code on the website user’s browser. The Concrete CMS Security team scored this 2 with CVSS v3 vector AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N. This does not affect Concrete versions prior to version 9.

Concrete CMS version 9 before 9.2.5 is vulnerable to stored XSS in file tags and description attributes since administrator entered file attributes are not sufficiently sanitized in the Edit Attributes page. A rogue administrator could put malicious code into the file tags or description attributes and, when another administrator opens the same file for editing, the malicious code could execute. The Concrete CMS Security team scored this 2.4 with CVSS v3 vector AV:N/AC:L/PR:H/UI:R/S:U/C:L/I:N/A:N.

Concrete CMS version 9 before 9.2.5 is vulnerable to  stored XSS via the Role Name field since there is insufficient validation of administrator provided data for that field. A rogue administrator could inject malicious code into the Role Name field which might be executed when users visit the affected page. The Concrete CMS Security team scored this 2 with CVSS v3 vector AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:L/A:N https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator . Concrete versions below 9 do not include group types so they are not affected by this vulnerability.

icingaweb2-module-incubator is a working project of bleeding edge Icinga Web 2 libraries. In affected versions the class `gipfl\Web\Form` is the base for various concrete form implementations [1] and provides protection against cross site request forgery (CSRF) by default. This is done by automatically adding an element with a CSRF token to any form, unless explicitly disabled, but even if enabled, the CSRF token (sent during a client's submission of a form relying on it) is not validated. This enables attackers to perform changes on behalf of a user which, unknowingly, interacts with a prepared link or website. The version 0.22.0 is available to remedy this issue. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Vyper is a Pythonic Smart Contract Language for the EVM. There is an error in the stack management when compiling the `IR` for `sha3_64`. Concretely, the `height` variable is miscalculated. The vulnerability can't be triggered without writing the `IR` by hand (that is, it cannot be triggered from regular vyper code). `sha3_64` is used for retrieval in mappings. No flow that would cache the `key` was found so the issue shouldn't be possible to trigger when compiling the compiler-generated `IR`. This issue isn't triggered during normal compilation of vyper code so the impact is low. At the time of publication there is no patch available.

Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications running on PowerPC CPU based platforms if the CPU provides vector instructions. Impact summary: If an attacker can influence whether the POLY1305 MAC algorithm is used, the application state might be corrupted with various application dependent consequences. The POLY1305 MAC (message authentication code) implementation in OpenSSL for PowerPC CPUs restores the contents of vector registers in a different order than they are saved. Thus the contents of some of these vector registers are corrupted when returning to the caller. The vulnerable code is used only on newer PowerPC processors supporting the PowerISA 2.07 instructions. The consequences of this kind of internal application state corruption can be various - from no consequences, if the calling application does not depend on the contents of non-volatile XMM registers at all, to the worst consequences, where the attacker could get complete control of the application process. However unless the compiler uses the vector registers for storing pointers, the most likely consequence, if any, would be an incorrect result of some application dependent calculations or a crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of this AEAD cipher is with TLS protocol versions 1.2 and 1.3. If this cipher is enabled on the server a malicious client can influence whether this AEAD cipher is used. This implies that TLS server applications using OpenSSL can be potentially impacted. However we are currently not aware of any concrete application that would be affected by this issue therefore we consider this a Low severity security issue.

Concrete CMS 9 before 9.2.3 is vulnerable to Cross Site Request Forgery (CSRF) via /ccm/system/dialogs/logs/delete_all/submit. An attacker can force an admin user to delete server report logs on a web application to which they are currently authenticated.

OpenZeppelin Contracts is a library for smart contract development. A merge issue when porting the 5.0.1 patch to the 4.9 branch caused a line duplication. In the version of `Multicall.sol` released in `@openzeppelin/contracts@4.9.4` and `@openzeppelin/contracts-upgradeable@4.9.4`, all subcalls are executed twice. Concretely, this exposes a user to unintentionally duplicate operations like asset transfers. The duplicated delegatecall was removed in version 4.9.5. The 4.9.4 version is marked as deprecated. Users are advised to upgrade. There are no known workarounds for this issue.

Concrete CMS before 8.5.13 and 9.x before 9.2.2 allows stored XSS on the Admin page via an uploaded file name.