ghsa

### Summary By default, the Redis database server is not password-protected. Consequently, an attacker with access to the Redis server can gain read/write access to the data in Redis. The attacker can also modify the "mfst" (manifest) key to cause ArgoCD to execute any deployment, potentially leveraging ArgoCD's high privileges to take over the cluster. Updating the "cacheEntryHash" in the manifest JSON is necessary, but since it doesn't use a private key for signing its integrity, a simple script can generate a new FNV64a hash matching the new manifest values. The repo-server, unable to verify if its cache is compromised, will read the altered "mfst" key and initiate an update process for the injected deployment. It's also possible to edit the "app|resources-tree" key, causing the ArgoCD server to load any Kubernetes resource into the live manifest section of the app preview. This could lead to an information leak. The fact that the cache in Redis is neither signed nor validated, co...

### Impact When storing unbounded types in a `BTreeMap`, a node is represented as a linked list of "memory chunks". It was discovered recently that when we deallocate a node, in some cases only the first memory chunk is deallocated, and the rest of the memory chunks remain (incorrectly) allocated, causing a memory leak. In the worst case, depending on how a canister uses the `BTreeMap`, an adversary could interact with the canister through its API and trigger interactions with the map that keep consuming memory due to the memory leak. This could potentially lead to using an excessive amount of memory, or even running out of memory. This issue has been fixed in #212 by changing the logic for deallocating nodes to ensure that all of a node's memory chunks are deallocated. Tests have been added to prevent regressions of this nature moving forward. **Note:** Users of stable-structure < 0.6.0 are not affected. ### Patches The problem has been fixed in PR #212 and users are asked to upg...

### Impact Stored Cross-site scripting (XSS) enable attackers that have access to backoffice to bring malicious content into a website or application. ### Affected versions Umbraco CMS >= 8.00 ### Patches This is fixed in 8.18.13, 10.8.4, 12.3.7, 13.1.1 by implementing IHtmlSanitizer

### Impact This CVE covers the ability of 3rd party websites to access routes and upload files to users running Gradio applications locally. For example, the malicious owners of [www.dontvisitme.com](http://www.dontvisitme.com/) could put a script on their website that uploads a large file to http://localhost:7860/upload and anyone who visits their website and has a Gradio app will now have that large file uploaded on their computer ### Patches Yes, the problem has been patched in Gradio version 4.19.2 or higher. We have no knowledge of this exploit being used against users of Gradio applications, but we encourage all users to upgrade to Gradio 4.19.2 or higher. Fixed in: https://github.com/gradio-app/gradio/commit/84802ee6a4806c25287344dce581f9548a99834a CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-1727

### Background There is currently no escaping or validation of the `callback` parameter that can be passed to various OMERO.web endpoints that have JSONP enabled. One such endpoint is `/webclient/imgData/...`. As we only really use these endpoints with jQuery's own callback name generation [^1] it is quite difficult or even impossible to exploit this in vanilla OMERO.web. However, these metadata endpoints are likely to be used by many plugins. [^1]: https://learn.jquery.com/ajax/working-with-jsonp/ ### Impact OMERO.web before 5.25.0 ### Patches Users should upgrade to 5.26.0 or higher ### Workarounds None ### References * https://stackoverflow.com/questions/2777021/do-i-need-to-sanitize-the-callback-parameter-from-a-jsonp-call * https://stackoverflow.com/questions/1661197/what-characters-are-valid-for-javascript-variable-names For more information If you have any questions or comments about this advisory: Open an issue in [omero-web](https://github.com/ome/omero-web) Email us a...

### Impact Umbraco have an endpoint that is vulnerable to open redirects. The endpoint is protected so it requires the user to be signed into backoffice, before the vulnerability is exposed. ### Affected Version \>= 8.18.5, >= 10.5.0, >= 12.0.0, >= 13.0.0 ### Patches 8.18.14, 10.8.6, 12.3.10, 13.3.1

There is a risk of an IV collision using the awskms or aesgcm provider. NIST SP 800-38D section 8.3 states that it is unsafe to encrypt more than 2^32 plaintexts under the same key when using a random IV. The limit could easily be reached given the use case of database column encryption. Ciphertexts are likely to be persisted and stored together. IV collision could enable an attacker with access to the ciphertexts to decrypt all messages encrypted with the affected key. The aesgcm provider cannot be fixed without a breaking change, so users should not encrypt more than 2^32 values with any key. The awskms package can be fixed without a breaking change by switching to a counter-based IV.

The ibc-go module is affected by the Inter-Blockchain Communication (IBC) protocol "Huckleberry" vulnerability.

Minder engine is susceptible to a denial of service from memory exhaustion that can be triggered from maliciously created templates. Minder engine uses templating to generate strings for various use cases such as URLs, messages for pull requests, descriptions for advisories. In some cases can the user control both the template and the params for it, and in a subset of these cases, Minder reads the generated template entirely into memory. When Minders templating meets both of these conditions, an attacker is able to generate large enough templates that Minder will exhaust memory and crash. One of these places is the REST ingester: https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L115-L123 With control over both endpoint and `retp` on the following line: https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L121 … an attacker can make Minder generat...

## Impact If a malicious actor is able to trigger Trivy to scan container images from a crafted malicious registry, it could result in the leakage of credentials for legitimate registries such as AWS Elastic Container Registry (ECR), Google Cloud Artifact/Container Registry, or Azure Container Registry (ACR). These tokens can then be used to push/pull images from those registries to which the identity/user running Trivy has access. Taking AWS as an example, the leakage only occurs when Trivy is able to transparently obtain registry credentials from the default [credential provider chain](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/#specifying-credentials). You are affected if Trivy is executed in any of the following situations: - The environment variables contain static AWS credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN) that have access to ECR. - Within a Pod running on an EKS cluster that has been assigned a role with access to ECR using an [...