ghsa

### Summary When logging in with the correct username and incorrect weak password, the user receives the notification, that their password is too weak. However when an incorrect username is provided along side with weak password, the application responds with ’Invalid credentials’ notification. This difference could be used to perform username enumeration. ### Patches Update to 5.1.1 or later. If you have any questions or comments about this advisory: Email us at [[email protected]](mailto:[email protected])

### Impact Mautic allows you to update the application via an upgrade script. The upgrade logic isn't shielded off correctly, which may lead to vulnerable situation. This vulnerability is mitigated by the fact that Mautic needs to be installed in a certain way to be vulnerable ### Patches Please upgrade to 4.4.1 or 5.1.1 or later. ### Workarounds None. ### For more information If you have any questions or comments about this advisory: * Email us at [[email protected]](mailto:[email protected])

### Summary Prior to this patch, a stored XSS vulnerability existed in the contact tracking and page hits report. ### Patches Please update to 4.4.13 or 5.1.1 or later. ### Workarounds None ### References https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS) https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting If you have any questions or comments about this advisory: Email us at [[email protected]](mailto:[email protected])

## Summary Prior to this patch being applied, Mautic's tracking was vulnerable to Cross-Site Scripting through the Page URL variable. ## Patches Please update to 4.4.13 or 5.1.1 or later. ## Workarounds None ## References https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS) https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting If you have any questions or comments about this advisory: Email us at [[email protected]](mailto:[email protected])

### Impact With access to edit a Mautic form, the attacker can add Cross-Site Scripting stored in the html filed. This could be used to steal sensitive information from the user's current session. ### Patches Upgrade to 4.4.13 or 5.1.1 or later. ### Workarounds None ### References - https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS) - https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/02-Testing_for_Stored_Cross_Site_Scripting If you have any questions or comments about this advisory: Email us at [[email protected]](mailto:[email protected])

CoreDNS through 1.10.1 enables attackers to achieve DNS cache poisoning and inject fake responses via a birthday attack.

exec.CommandContext in Chaosblade 0.3 through 1.7.3, when server mode is used, allows OS command execution via the cmd parameter without authentication.

A vulnerability has been discovered and fixed in Mesop that could potentially allow unauthorized access to files on the server hosting the Mesop application. The vulnerability was related to insufficient input validation in a specific endpoint. This could have allowed an attacker to access files not intended to be served. Users are strongly advised to update to the latest version of Mesop immediately. The latest version includes a fix for this vulnerability. We would like to thank @Letm3through for reporting this issue and proposing mitigations to address this issue.

### Impact The logic in place to facilitate the update process via the user interface lacks access control to verify if permission exists to perform the tasks. Prior to this patch being applied it might be possible for an attacker to access the Mautic version number or to execute parts of the upgrade process without permission. As upgrading in the user interface is deprecated, this functionality is no longer required. ### Patches Upgrade to 4.4.13 or 5.1.1 or later. ### Workarounds None. ### For more information If you have any questions or comments about this advisory: * Email us at [[email protected]](mailto:[email protected])

## Background Multiple caveats over the same indirect subject type on the same relation can result in no permission being returned when permission is expected For example, given this schema: ``` definition user {} caveat somecaveat(somefield int) { somefield == 42 } definition group { relation member: user } definition resource { relation viewer: group#member with somecaveat permission view = folder->view } ``` If the resource has multiple groups, and each group is caveated, it is possible for the returned permission to be "no permission" when permission is expected. ## Impact Permission is returned as NO_PERMISSION when PERMISSION is expected on the CheckPermission API. ## Workarounds Do not use caveats or do not use caveats on an indirect subject type with multiple entries