ghsa

### Impact Pimcore offers developers listing classes to make querying data easier. This listing classes also allow to order or group the results based on one or more columns which should be quoted by default. The actual issue is that quoting is not done properly in both cases, so there's the theoretical possibility to inject custom SQL if the developer is using this methods with input data and not doing proper input validation in advance and so relies on the auto-quoting being done by the listing classes. ##### Example: ```php // request url: https://example.com/foo?groupBy=o_id`; SELECT SLEEP(20);-- $list = new DataObject\Car\Listing(); $list->setOrderKey($request->get('orderBy')); $list->setGroupBy($request->get('groupBy')); $list->load(); ``` ### Patches Upgrade to >= 10.4.4 or apply the following patch manually: https://github.com/pimcore/pimcore/commit/21559c6bf0e4e828d33ff7af6e88caecb5ac6549.patch ### Workarounds Apply this patch manually: https://github.com/pimcore/pim...

### Impact Authenticated Stored XSS in Administration ### Patches We recommend updating to version 5.7.12. You can get the update to 5.7.12 regularly via the Auto-Updater or directly via the download overview. https://www.shopware.com/de/changelog-sw5/#5-7-12 For older versions you can use the Security Plugin: https://store.shopware.com/en/swag575294366635f/shopware-security-plugin.html ### References https://docs.shopware.com/en/shopware-5-en/security-updates/security-update-06-2022

### Impact When parsing untrusted rulex expressions, the stack may overflow, possibly enabling a Denial of Service attack. This happens when parsing an expression with several hundred levels of nesting, causing the process to abort immediately. This is a security concern for you, if - your service parses untrusted rulex expressions (expressions provided by an untrusted user), and - your service becomes unavailable when the process running rulex aborts due to a stack overflow. ### Patches The crash is fixed in version **0.4.3**. Affected users are advised to update to this version. ### Workarounds None. ### For more information If you have any questions or comments about this advisory: * Open an issue in [rulex](https://github.com/rulex-rs/rulex/issues) * Email me at [[email protected]](mailto:[email protected]) ### Credits Credit for finding these bugs goes to - [evanrichter](https://github.com/evanrichter) - [ForAllSecure Mayhem](https://forallsecure.com/) - [cargo fuzz...

Newtonsoft.Json prior to version 13.0.1 is vulnerable to Insecure Defaults due to improper handling of StackOverFlow exception (SOE) whenever nested expressions are being processed. Exploiting this vulnerability results in Denial Of Service (DoS), and it is exploitable when an attacker sends 5 requests that cause SOE in time frame of 5 minutes. This vulnerability affects Internet Information Services (IIS) Applications.

There is a Cross Site Scripting Stored (XSS) vulnerability in NukeViet CMS before 4.5.02.

Webkul krayin crm before 1.2.2 is vulnerable to Cross Site Scripting (XSS).

In Spring Cloud Function versions prior to 3.2.6, it is possible for a user who directly interacts with framework provided lookup functionality to cause a denial-of-service condition due to the caching issue in the Function Catalog component of the framework.

### Impact All versions of Argo CD starting with v0.7.0 are vulnerable to an uncontrolled memory consumption bug, allowing an authorized malicious user to crash the [repo-server](https://argo-cd.readthedocs.io/en/stable/operator-manual/architecture/#repository-server) service. The repo-server is a critical component of Argo CD, so crashing the repo-server effectively denies core Argo CD services (such as syncing Application updates). To achieve denial of service, the attacker must be an authenticated Argo CD user authorized to deploy Applications from a repository which contains (or can be made to contain) a large file. ### Patches A patch for this vulnerability has been released in the following Argo CD versions: * v2.4.1 * v2.3.5 * v2.2.10 * v2.1.16 **The patch introduces a new `reposerver.max.combined.directory.manifests.size` config parameter, which you should tune before upgrading in production.** It caps the maximum total file size of .yaml/.yml/.json files in directory-ty...

### Impact When parsing untrusted rulex expressions, rulex may crash, possibly enabling a Denial of Service attack. This happens when the expression contains a multi-byte UTF-8 code point in a string literal or after a backslash, because rulex tries to slice into the code point and panics as a result. This is a security concern for you, if - your service parses untrusted rulex expressions (expressions provided by an untrusted user), and - your service becomes unavailable when the thread running rulex panics. ### Patches The crashes are fixed in version **0.4.3**. Affected users are advised to update to this version. ### Workarounds You can use `catch_unwind` to recover from panics. ### For more information If you have any questions or comments about this advisory: * Open an issue in [rulex](https://github.com/rulex-rs/rulex/issues) * Email me at [[email protected]](mailto:[email protected]) ### Credits Credit for finding these bugs goes to - [cargo fuzz](https://github.c...

### Impact `Authorization` and `Cookie` headers on requests are sensitive information. On making a request which responds with a redirect to a URI with a different port, if we choose to follow it, we should remove the `Authorization` and `Cookie` headers from the request, before containing. Previously, we would only consider a change in host or scheme downgrade. Now, we consider any change in host, port or scheme to be a change in origin. ### Patches Affected Guzzle 7 users should upgrade to Guzzle 7.4.5 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.8 or 7.4.5. ### Workarounds An alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together. ### References * [RFC9110 Section 15.4](https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx) * [CVE-2022-27776](http...