ghsa

### Impact An unsanitized payload sent by an Integration platform integration allows the storage of arbitrary HTML tags on the Sentry side. This payload could subsequently be rendered on the Issues page, creating a Stored Cross-Site Scripting (XSS) vulnerability. This vulnerability might lead to the execution of arbitrary scripts in the context of a user’s browser. Self-hosted Sentry users may be impacted if untrustworthy Integration platform integrations send external issues to their Sentry instance. ### Patches The patch has been released in [Sentry 24.7.1](https://github.com/getsentry/self-hosted/releases/tag/24.7.1) ### Workarounds For Sentry SaaS customers, no action is needed. This has been patched on July 22, and even prior to the fix, the exploitation was not possible due to the strict Content Security Policy deployed on sentry.io site. For self-hosted users, we strongly recommend upgrading Sentry to the latest version. If it is not possible, you could [enable CSP on your s...

Exposure of temporary credentials in logs in Apache Arrow Rust Object Store (`object_store` crate), version 0.10.1 and earlier on all platforms using AWS WebIdentityTokens.  On certain error conditions, the logs may contain the OIDC token passed to AssumeRoleWithWebIdentity https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html . This allows someone with access to the logs to impersonate that identity, including performing their own calls to AssumeRoleWithWebIdentity, until the OIDC token expires. Typically OIDC tokens are valid for up to an hour, although this will vary depending on the issuer. Users are recommended to use a different AWS authentication mechanism, disable logging or upgrade to version 0.10.2, which fixes this issue. Details: When using AWS WebIdentityTokens with the object_store crate, in the event of a failure and automatic retry, the underlying reqwest error, including the full URL with the credentials, potentially in the paramet...

A vulnerability has been discovered in vue-template-compiler, that allows an attacker to perform XSS via prototype pollution. The attacker could change the prototype chain of some properties such as `Object.prototype.staticClass` or `Object.prototype.staticStyle` to execute arbitrary JavaScript code. Vue 2 has reached End-of-Life. This vulnerability has been patched in Vue 3.

## Summary Versions of `tf2-item-format` since at least `4.2.6` are vulnerable to a Regular Expression Denial of Service (ReDoS) attack when parsing crafted user input. ## Tested Versions - `5.9.13` - `5.8.10` - `5.7.0` - `5.6.17` - `4.3.5` - `4.2.6` ### v5 Upgrade package to `^5.9.14` ### v4 No patch exists. Please consult the [v4 to v5 migration guide](https://github.com/danocmx/node-tf2-item-format?tab=readme-ov-file#migrating-from-v4-to-v5) to upgrade to v5. If upgrading to v5 is not possible, fork the module repository and implement the fix detailed below. ## Impact This vulnerability can be exploited by an attacker to perform DoS attacks on any service that uses any `tf2-item-format` to parse user input.

### Impact _What kind of vulnerability is it? Who is impacted?_ A vulnerability discovered in the ImageSharp library, where the processing of specially crafted files can lead to excessive memory usage in the Gif decoder. The vulnerability is triggered when ImageSharp attempts to process image files that are designed to exploit this flaw. ### Patches _Has the problem been patched? What versions should users upgrade to?_ The problem has been patched. All users are advised to upgrade to v3.1.5 or v2.1.9. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Before calling `Image.Decode(Async)`, use `Image.Identify` to determine the image dimensions in order to enforce a limit. ### References _Are there any links users can visit to find out more?_ - https://github.com/SixLabors/ImageSharp/pull/2759 - https://github.com/SixLabors/ImageSharp/pull/2764 - https://github.com/SixLabors/ImageSharp/pull/2770 - ImageSharp: [Security Considerations...

### Impact An Out-of-bounds Write vulnerability has been found in the ImageSharp gif decoder, allowing attackers to cause a crash using a specially crafted gif. This can potentially lead to denial of service. ### Patches The problem has been patched. All users are advised to upgrade to v3.1.5 or v2.1.9. ### Workarounds None. ### References https://github.com/SixLabors/ImageSharp/pull/2754 https://github.com/SixLabors/ImageSharp/pull/2756

### Summary The issue here is that we pass the secret content as one of the args via CLI. This issue may affect any of our charms that are using: Juju (>=3.0), Juju secrets and not correctly capturing and processing `subprocess.CalledProcessError`. There are two points that may log this command, in different files: First, if there is an error during a secret handling, there will be a `subprocess.CalledProcessError`, which will contain the CLI comand + all its args. This is going to be logged in any logging level. This exception, if not caught by the charm, will bubble up to the `/var/log/juju/` logs and syslog journal. Now, on Ubuntu 22.04, these logs are protected with: ``` $ juju ssh -m controller 0 -- ls -la /var/log/juju/ total 224 drwxr-xr-x 2 syslog adm 4096 Jul 14 10:59 . drwxrwxr-x 9 root syslog 4096 Jul 14 10:58 .. -rw-r----- 1 syslog adm 20124 Jul 14 11:10 audit.log -rw-r----- 1 syslog adm 110432 Jul 14 11:10 logsink.log -rw-r----- 1 syslog adm 80783 Ju...

Previously, `MemBio::get_buf` called `slice::from_raw_parts` with a null-pointer, which violates the functions invariants, leading to undefined behavior. In debug builds this would produce an assertion failure. This is now fixed.

### Impact Users using the `ValidatingResolver` for DNSSEC validation can run into CPU exhaustion with specially crafted DNSSEC-signed zones. ### Patches Users should upgrade to dnsjava v3.6.0 ### Workarounds Although not recommended, only using a non-validating resolver, will remove the vulnerability. ### References https://www.athene-center.de/en/keytrap

### Summary This report details a security vulnerability in Argo CD, where an unauthenticated attacker can send a specially crafted large JSON payload to the /api/webhook endpoint, causing excessive memory allocation that leads to service disruption by triggering an Out Of Memory (OOM) kill. The issue poses a high risk to the availability of Argo CD deployments. ### Details The webhook server always listens to requests. By default, the endpoint doesn't require authentication. It's possible to send a large, malicious request with headers (in this case "X-GitHub-Event: push") that will make ArgoCD start allocating memory to parse the incoming request. Since the request can be constructed client-side without allocating large amounts of memory, it can be arbitrarily large. Eventually, the argocd-server component will get OOMKilled as it consumes all its available memory. The fix would be to enforce a limit on the size of the request being parsed. ### PoC Port-forward to the argocd-serve...