ghsa

This affects versions of the package opencart/opencart from 4.0.0.0. A reflected XSS issue was identified in the filename parameter of the admin tool/log route. An attacker could obtain a user's token by tricking the user to click on a maliciously crafted URL. The user is then prompted to login and redirected again upon authentication with the payload automatically executing. If the attacked user has admin privileges, this vulnerability could be used as the start of a chain of exploits like Zip Slip or arbitrary file write vulnerabilities in the admin functionality. **Notes:** 1) This is only exploitable if the attacker knows the name or path of the admin directory. The name of the directory is "admin" by default but there is a pop-up in the dashboard warning users to rename it. 2) The fix for this vulnerability is incomplete. The redirect is removed so that it is not possible for an attacker to control the redirect post admin login anymore, but it is still possible to exploit this ...

This affects versions of the package opencart/opencart from 0.0.0. An SQL Injection issue was identified in the Divido payment extension for OpenCart, which is included by default in version 3.0.3.9. As an anonymous unauthenticated user, if the Divido payment module is installed (it does not have to be enabled), it is possible to exploit SQL injection to gain unauthorised access to the backend database. For any site which is vulnerable, any unauthenticated user could exploit this to dump the entire OpenCart database, including customer PII data.

This affects versions of the package opencart/opencart from 4.0.0.0. A reflected XSS issue was identified in the redirect parameter of customer account/login route. An attacker can inject arbitrary HTML and Javascript into the page response. As this vulnerability is present in the account functionality it could be used to target and attack customers of the OpenCart shop. **Notes:** 1) The fix for this vulnerability is incomplete

### Impact The LDAP testing endpoint allows to change the Connection URL independently of and without having to re-enter the currently configured LDAP bind credentials. An attacker with admin access (permission manage-realm) can change the LDAP host URL ("Connection URL") to a machine they control. The Keycloak server will connect to the attacker's host and try to authenticate with the configured credentials, thus leaking them to the attacker. As a consequence, an attacker who has compromised the admin console/compromised a user with sufficient privileges can leak domain credentials and can now attack the domain. ### Acknowledgements Special thanks to Simon Wessling for reporting this issue and helping us improve our project

An issue was discovered in the events2 (aka Events 2) extension before 8.3.8 and 9.x before 9.0.6 for TYPO3. Missing access checks in the management plugin lead to an insecure direct object reference (IDOR) vulnerability with the potential to activate or delete various events for unauthenticated users.

An issue was discovered in the friendlycaptcha_official (aka Integration of Friendly Captcha) extension before 0.1.4 for TYPO3. The extension fails to check the requirement of the captcha field in submitted form data, allowing a remote user to bypass the captcha check. This only affects the captcha integration for the ext:form extension.

ClassGraph before 4.8.112 was not resistant to XML eXternal Entity (XXE) attacks.

### Impact A parsing vulnerability in lnd's onion processing logic led to a DoS vector due to excessive memory allocation. ### Patches The issue was patched in lnd [v0.17.0](https://github.com/lightningnetwork/lnd/releases/tag/v0.17.0-beta). Users should update to a version >= v0.17.0 to be protected. ### References Detailed blog post: https://morehouse.github.io/lightning/lnd-onion-bomb/ Developer discussion: https://delvingbitcoin.org/t/dos-disclosure-lnd-onion-bomb/979

An issue in the component `js2py.disable_pyimport()` of js2py up to v0.74 allows attackers to execute arbitrary code via a crafted API call.

### Background Use of an exclusion under an arrow that has multiple resources may resolve to `NO_PERMISSION` when permission is expected. For example, given this schema: ```zed definition user {} definition folder { relation member: user relation banned: user permission view = member - banned } definition resource { relation folder: folder permission view = folder->view } ``` If the resource exists under *multiple* folders and the user has access to view more than a single folder, SpiceDB may report the user does not have access due to a failure in the exclusion dispatcher to request that *all* the folders in which the user is a member be returned ### Impact Permission is returned as `NO_PERMISSION` when `PERMISSION` is expected on the `CheckPermission` API. ### Workarounds None