Source
ghsa
Improper handling of identifiers lead to a SQL injection vulnerability in the quoteNameStr method of the database package. Please note: the affected method is a protected method. It has no usages in the original packages in neither the 2.x nor 3.x branch and therefore the vulnerability in question can not be exploited when using the original database class. However, classes extending the affected class might be affected, if the vulnerable method is used.
An issue was discovered in Elasticsearch, where a large recursion using the Well-KnownText formatted string with nested GeometryCollection objects could cause a stackoverflow.
A flaw was discovered in Elasticsearch, where a large recursion using the innerForbidCircularReferences function of the PatternBank class could cause the Elasticsearch node to crash. A successful attack requires a malicious user to have read_pipeline Elasticsearch cluster privilege assigned to them.
### Summary An improper uploaded media ownership check can result in inadvertent deletion of media when a user is banned with content removal or purged. This can lead to deletion of media that was not uploaded by the banned/purged user. This also applies to purged communities, in which case all media posted in that community will get deleted without proper ownership check. This is limited to media with an `image/*` content-type returned by pict-rs. ### Details Lemmy did not associate users with media uploads until version 0.19.0 ([#3927](https://github.com/LemmyNet/lemmy/pull/3927)). Back when the first parts of content purging were implemented for 0.17.0 ([#1809](https://github.com/LemmyNet/lemmy/pull/1809)), it was therefore not possible to properly identify media belonging to a specific user for situations in which this data should get erased from pict-rs, Lemmy's media storage backend. Pict-rs deduplicates uploaded files transparently. As a result, it has two types of media delet...
### Impact It's possible to guess the deepLinkCode of an Document to open documents of other customers ### Patches Update to Shopware 6.6.10.3 or 6.5.8.17 ### Workarounds For older versions of 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
### Impact The Shopware application API contains a search functionality which enables users to search through information stored within their Shopware instance. The searches performed by this function can be aggregated using the parameters in the “aggregations” object. The ‘name’ field in this “aggregations” **in nested** object is vulnerable SQL-injection and can be exploited using SQL parameters. ### Patches Update to Shopware 6.6.10.3 or 6.5.8.17 ### Workarounds For older versions of 6.4 corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version. ### Credit [Redteam Pentesting](https://www.redteam-pentesting.de/)
### Summary An HTML injection issue allows users with access to the email sending functionality to inject arbitrary HTML code into emails sent via the admin interface, potentially leading to session cookie theft and the alteration of page content. ### Details The vulnerability was discovered in the `/admin/email/send-test-email` endpoint using the `POST` method. The vulnerable parameter is `content`, which permits the injection of arbitrary HTML code during the email sending process. While JavaScript code injection is blocked through filtering, HTML code injection remains possible. ### PoC To reproduce the vulnerability, a user must fill out the email's content form with the desired HTML payload.  ### Impact  This HTML injection vulnerability can potentially enable phishing attacks by allo...
### Impact It's possible to pass long passwords that leads to Denial Of Service via forms in Storefront forms or Store-API. ### Patches Update to Shopware 6.6.10.3 or 6.5.8.17 ### Workarounds For older versions of 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
### Impact Through the store-api it is possible as a attacker to check if a specific e-mail address has an account in the shop. Using the store-api endpoint `/store-api/account/recovery-password` you get the response ``` {"errors":[{"status":"404","code":"CHECKOUT__CUSTOMER_NOT_FOUND","title":"Not Found","detail":"No matching customer for the email \[email protected]\u0022 was found.","meta":{"parameters":{"email":"[email protected]"}}}]} ``` which indicates clearly that there is no account for this customer. In contrast you get a success response if the account was found. ### Patches Update to Shopware 6.6.10.3 or 6.5.8.17 ### Workarounds For older versions of 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
The broadcast channel internally calls `clone` on the stored value when receiving it, and only requires `T:Send`. This means that using the broadcast channel with values that are `Send` but not `Sync` can trigger unsoundness if the `clone` implementation makes use of the value being `!Sync`. Thank you to Austin Bonander for finding and reporting this issue.