deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-2q97-m5rc-p3gp
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 1.5.8
Patched in: 1.5.8

Summary: CosmWasm VM Incorrect metering

Details:
# CWA-2024-007

**Severity**

Medium (Moderate + Likely)[^1]

**Affected versions:**

- wasmvm >= 2.1.0, < 2.1.3
- wasmvm >= 2.0.0, < 2.0.4
- wasmvm < 1.5.5
- cosmwasm-vm >= 2.1.0, < 2.1.4
- cosmwasm-vm >= 2.0.0, < 2.0.7
- cosmwasm-vm < 1.5.8

**Patched versions:**

- wasmvm 1.5.5, 2.0.4, 2.1.3
- cosmwasm-vm 1.5.8, 2.0.7, 2.1.4

## Description of the bug

(Blank for now. We'll add more detail once chains had a chance to upgrade.)

## Patch

- 1.5: https://github.com/CosmWasm/cosmwasm/commit/16eabd681790508b13dac8e67f9e6e61045240ea
- 2.0: https://github.com/CosmWasm/cosmwasm/commit/0e70bd83119b02f99a2c0397f0913e0803750fd9
- 2.1: https://github.com/CosmWasm/cosmwasm/commit/f5bf24f3acadca2892afd58cc3ce5fdeb932d492

## Applying the patch

The patch will be shipped in releases of wasmvm. You can update more or less as follows:

1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to 1.5.5, 2.0.4, 2.1.3 depending on which minor version you are; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.5, 2.0.4, 2.1.3.
5. Follow your regular practices to deploy chain upgrades.

To double check if the correct library version is loaded at runtime, use this query:
`<appd> query wasm libwasmvm-version`. It must show 1.5.5, 2.0.4 or 2.1.3.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-08-28: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-08-30: Confio security contributors confirm the report.
- 2024-09-02: Confio developed the patch internally.
- 2024-09-23: Patch is released.

[^1]: following Amulet's Severity Classification Framework ACMv1: https://github.com/interchainio/security/blob/e0227a1fb4059144aab4f6003eeee7f09912db3a/resources/CLASSIFICATION_MATRIX.md
GitHub Security Advisory: GHSA-2q97-m5rc-p3gp
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 2.0.0, < 2.0.7
Patched in: 2.0.7

Summary: CosmWasm VM Incorrect metering

Details:
# CWA-2024-007

**Severity**

Medium (Moderate + Likely)[^1]

**Affected versions:**

- wasmvm >= 2.1.0, < 2.1.3
- wasmvm >= 2.0.0, < 2.0.4
- wasmvm < 1.5.5
- cosmwasm-vm >= 2.1.0, < 2.1.4
- cosmwasm-vm >= 2.0.0, < 2.0.7
- cosmwasm-vm < 1.5.8

**Patched versions:**

- wasmvm 1.5.5, 2.0.4, 2.1.3
- cosmwasm-vm 1.5.8, 2.0.7, 2.1.4

## Description of the bug

(Blank for now. We'll add more detail once chains had a chance to upgrade.)

## Patch

- 1.5: https://github.com/CosmWasm/cosmwasm/commit/16eabd681790508b13dac8e67f9e6e61045240ea
- 2.0: https://github.com/CosmWasm/cosmwasm/commit/0e70bd83119b02f99a2c0397f0913e0803750fd9
- 2.1: https://github.com/CosmWasm/cosmwasm/commit/f5bf24f3acadca2892afd58cc3ce5fdeb932d492

## Applying the patch

The patch will be shipped in releases of wasmvm. You can update more or less as follows:

1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to 1.5.5, 2.0.4, 2.1.3 depending on which minor version you are; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.5, 2.0.4, 2.1.3.
5. Follow your regular practices to deploy chain upgrades.

To double check if the correct library version is loaded at runtime, use this query:
`<appd> query wasm libwasmvm-version`. It must show 1.5.5, 2.0.4 or 2.1.3.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-08-28: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-08-30: Confio security contributors confirm the report.
- 2024-09-02: Confio developed the patch internally.
- 2024-09-23: Patch is released.

[^1]: following Amulet's Severity Classification Framework ACMv1: https://github.com/interchainio/security/blob/e0227a1fb4059144aab4f6003eeee7f09912db3a/resources/CLASSIFICATION_MATRIX.md
GitHub Security Advisory: GHSA-2q97-m5rc-p3gp
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 2.1.0, < 2.1.4
Patched in: 2.1.4

Summary: CosmWasm VM Incorrect metering

Details:
# CWA-2024-007

**Severity**

Medium (Moderate + Likely)[^1]

**Affected versions:**

- wasmvm >= 2.1.0, < 2.1.3
- wasmvm >= 2.0.0, < 2.0.4
- wasmvm < 1.5.5
- cosmwasm-vm >= 2.1.0, < 2.1.4
- cosmwasm-vm >= 2.0.0, < 2.0.7
- cosmwasm-vm < 1.5.8

**Patched versions:**

- wasmvm 1.5.5, 2.0.4, 2.1.3
- cosmwasm-vm 1.5.8, 2.0.7, 2.1.4

## Description of the bug

(Blank for now. We'll add more detail once chains had a chance to upgrade.)

## Patch

- 1.5: https://github.com/CosmWasm/cosmwasm/commit/16eabd681790508b13dac8e67f9e6e61045240ea
- 2.0: https://github.com/CosmWasm/cosmwasm/commit/0e70bd83119b02f99a2c0397f0913e0803750fd9
- 2.1: https://github.com/CosmWasm/cosmwasm/commit/f5bf24f3acadca2892afd58cc3ce5fdeb932d492

## Applying the patch

The patch will be shipped in releases of wasmvm. You can update more or less as follows:

1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to 1.5.5, 2.0.4, 2.1.3 depending on which minor version you are; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.5, 2.0.4, 2.1.3.
5. Follow your regular practices to deploy chain upgrades.

To double check if the correct library version is loaded at runtime, use this query:
`<appd> query wasm libwasmvm-version`. It must show 1.5.5, 2.0.4 or 2.1.3.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-08-28: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-08-30: Confio security contributors confirm the report.
- 2024-09-02: Confio developed the patch internally.
- 2024-09-23: Patch is released.

[^1]: following Amulet's Severity Classification Framework ACMv1: https://github.com/interchainio/security/blob/e0227a1fb4059144aab4f6003eeee7f09912db3a/resources/CLASSIFICATION_MATRIX.md
GitHub Security Advisory: GHSA-vmqh-5232-v43r
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 1.5.8
Patched in: 1.5.8

Summary: Panic in wasmvm can slow down block production

Details:
# CWA-2024-008

**Severity**

Medium (Moderate + Likely)[^1]

**Affected versions:**

- wasmvm >= 2.1.0, < 2.1.3
- wasmvm >= 2.0.0, < 2.0.4
- wasmvm < 1.5.5
- cosmwasm-vm >= 2.1.0, < 2.1.4
- cosmwasm-vm >= 2.0.0, < 2.0.7
- cosmwasm-vm < 1.5.8

**Patched versions:**

- wasmvm 1.5.5, 2.0.4, 2.1.3
- cosmwasm-vm 1.5.8, 2.0.7, 2.1.4

## Description of the bug

(Blank for now. We'll add more detail once chains had a chance to upgrade.)

## Patch

- 1.5: https://github.com/CosmWasm/cosmwasm/commit/edcdbc520d4f5521eed42de6e[PII_REDACTED]e91fd
- 2.0: https://github.com/CosmWasm/cosmwasm/commit/f63429ca59eb44dd5d780c[PII_REDACTED]37091e4
- 2.1: https://github.com/CosmWasm/cosmwasm/commit/108e7dcbf9c21df0fa83f355ad3a7355d7f220cb

## Applying the patch

The patch will be shipped in releases of wasmvm. You can update more or less as follows:

1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to 1.5.5, 2.0.4, 2.1.3 depending on which minor version you are; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.5, 2.0.4, 2.1.3.
5. Follow your regular practices to deploy chain upgrades.

To double check if the correct library version is loaded at runtime, use this query:
`<appd> query wasm libwasmvm-version`. It must show 1.5.5, 2.0.4 or 2.1.3.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-08-22: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-08-23: Confio security contributors confirm the report.
- 2024-09-09: Confio developed the patch internally.
- 2024-09-23: Patch is released.

[^1]: following Amulet's Severity Classification Framework ACMv1: https://github.com/interchainio/security/blob/e0227a1fb4059144aab4f6003eeee7f09912db3a/resources/CLASSIFICATION_MATRIX.md
GitHub Security Advisory: GHSA-vmqh-5232-v43r
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 2.0.0, < 2.0.7
Patched in: 2.0.7

Summary: Panic in wasmvm can slow down block production

Details:
# CWA-2024-008

**Severity**

Medium (Moderate + Likely)[^1]

**Affected versions:**

- wasmvm >= 2.1.0, < 2.1.3
- wasmvm >= 2.0.0, < 2.0.4
- wasmvm < 1.5.5
- cosmwasm-vm >= 2.1.0, < 2.1.4
- cosmwasm-vm >= 2.0.0, < 2.0.7
- cosmwasm-vm < 1.5.8

**Patched versions:**

- wasmvm 1.5.5, 2.0.4, 2.1.3
- cosmwasm-vm 1.5.8, 2.0.7, 2.1.4

## Description of the bug

(Blank for now. We'll add more detail once chains had a chance to upgrade.)

## Patch

- 1.5: https://github.com/CosmWasm/cosmwasm/commit/edcdbc520d4f5521eed42de6e[PII_REDACTED]e91fd
- 2.0: https://github.com/CosmWasm/cosmwasm/commit/f63429ca59eb44dd5d780c[PII_REDACTED]37091e4
- 2.1: https://github.com/CosmWasm/cosmwasm/commit/108e7dcbf9c21df0fa83f355ad3a7355d7f220cb

## Applying the patch

The patch will be shipped in releases of wasmvm. You can update more or less as follows:

1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to 1.5.5, 2.0.4, 2.1.3 depending on which minor version you are; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.5, 2.0.4, 2.1.3.
5. Follow your regular practices to deploy chain upgrades.

To double check if the correct library version is loaded at runtime, use this query:
`<appd> query wasm libwasmvm-version`. It must show 1.5.5, 2.0.4 or 2.1.3.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-08-22: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-08-23: Confio security contributors confirm the report.
- 2024-09-09: Confio developed the patch internally.
- 2024-09-23: Patch is released.

[^1]: following Amulet's Severity Classification Framework ACMv1: https://github.com/interchainio/security/blob/e0227a1fb4059144aab4f6003eeee7f09912db3a/resources/CLASSIFICATION_MATRIX.md
GitHub Security Advisory: GHSA-vmqh-5232-v43r
Package: cosmwasm-vm (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 2.1.0, < 2.1.4
Patched in: 2.1.4

Summary: Panic in wasmvm can slow down block production

Details:
# CWA-2024-008

**Severity**

Medium (Moderate + Likely)[^1]

**Affected versions:**

- wasmvm >= 2.1.0, < 2.1.3
- wasmvm >= 2.0.0, < 2.0.4
- wasmvm < 1.5.5
- cosmwasm-vm >= 2.1.0, < 2.1.4
- cosmwasm-vm >= 2.0.0, < 2.0.7
- cosmwasm-vm < 1.5.8

**Patched versions:**

- wasmvm 1.5.5, 2.0.4, 2.1.3
- cosmwasm-vm 1.5.8, 2.0.7, 2.1.4

## Description of the bug

(Blank for now. We'll add more detail once chains had a chance to upgrade.)

## Patch

- 1.5: https://github.com/CosmWasm/cosmwasm/commit/edcdbc520d4f5521eed42de6e[PII_REDACTED]e91fd
- 2.0: https://github.com/CosmWasm/cosmwasm/commit/f63429ca59eb44dd5d780c[PII_REDACTED]37091e4
- 2.1: https://github.com/CosmWasm/cosmwasm/commit/108e7dcbf9c21df0fa83f355ad3a7355d7f220cb

## Applying the patch

The patch will be shipped in releases of wasmvm. You can update more or less as follows:

1. Check the current wasmvm version: `go list -m github.com/CosmWasm/wasmvm`
2. Bump the `github.com/CosmWasm/wasmvm` dependency in your go.mod to 1.5.5, 2.0.4, 2.1.3 depending on which minor version you are; `go mod tidy`; commit.
3. If you use the static libraries `libwasmvm_muslc.aarch64.a`/`libwasmvm_muslc.x86_64.a`, update them accordingly.
4. Check the updated wasmvm version: `go list -m github.com/CosmWasm/wasmvm` and ensure you see 1.5.5, 2.0.4, 2.1.3.
5. Follow your regular practices to deploy chain upgrades.

To double check if the correct library version is loaded at runtime, use this query:
`<appd> query wasm libwasmvm-version`. It must show 1.5.5, 2.0.4 or 2.1.3.

The patch is consensus breaking and requires a coordinated upgrade.

## Acknowledgement

This issue was found by meadow101 who reported it to the Cosmos Bug Bounty Program on HackerOne.

If you believe you have found a bug in the Interchain Stack or would like to contribute to the
program by reporting a bug, please see <https://hackerone.com/cosmos>.

## Timeline

- 2024-08-22: Confio receives a report through the Cosmos bug bounty program maintained by Amulet.
- 2024-08-23: Confio security contributors confirm the report.
- 2024-09-09: Confio developed the patch internally.
- 2024-09-23: Patch is released.

[^1]: following Amulet's Severity Classification Framework ACMv1: https://github.com/interchainio/security/blob/e0227a1fb4059144aab4f6003eeee7f09912db3a/resources/CLASSIFICATION_MATRIX.md
GitHub Security Advisory: GHSA-h97m-ww89-6jmq
Package: idna (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-697: Incorrect Comparison, CWE-1289: Improper Validation of Unsafe Equivalence in Input
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: `idna` accepts Punycode labels that do not produce any non-ASCII when decoded

Details:
`idna` 0.5.0 and earlier accepts Punycode labels that do not produce any non-ASCII output, which means that either ASCII labels or the empty root label can be masked such that they appear unequal without IDNA processing or when processed with a different implementation and equal when processed with `idna` 0.5.0 or earlier.

Concretely, `example.org` and `xn--example-.org` become equal after processing by `idna` 0.5.0 or earlier. Also, `example.org.xn--` and `example.org.` become equal after processing by `idna` 0.5.0 or earlier.

In applications using `idna` (but not in `idna` itself) this may be able to lead to privilege escalation when host name comparison is part of a privilege check and the behavior is combined with a client that resolves domains with such labels instead of treating them as errors that preclude DNS resolution / URL fetching and with the attacker managing to introduce a DNS entry (and TLS certificate) for an `xn--`-masked name that turns into the name of the target when processed by `idna` 0.5.0 or earlier.

## Remedy

Upgrade to `idna` 1.0.3 or later, if depending on `idna` directly, or to `url` 2.5.4 or later, if depending on `idna` via `url`. (This issue was fixed in `idna` 1.0.0, but versions earlier than 1.0.3 are not recommended for other reasons.)

When upgrading, please take a moment to read about [alternative Unicode back ends for `idna`](https://docs.rs/crate/idna_adapter/latest).

If you are using Rust earlier than 1.81 in combination with SQLx 0.8.2 or earlier, please also read an [issue](https://github.com/servo/rust-url/issues/992) about combining them with `url` 2.5.4 and `idna` 1.0.3.

## Additional information

This issue resulted from `idna` 0.5.0 and earlier implementing the UTS 46 specification literally on this point and the specification having this bug. The specification bug has been fixed in [revision 33 of UTS 46](https://www.unicode.org/reports/tr46/tr46-33.html#Modifications).

## Acknowledgements

Thanks to kageshiron for recognizing the security implications of this behavior.
GitHub Security Advisory: GHSA-vxcf-c7mx-pg53
Package: pyo3 (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.23.0, < 0.23.3
Patched in: 0.23.3

Summary: Build corruption when using `PYO3_CONFIG_FILE` environment variable

Details:
In PyO3 0.23.0 the `PYO3_CONFIG_FILE` environment variable used to configure builds regressed such that changing the environment variable would no longer trigger PyO3 to reconfigure and recompile. In combination with workflows using tools such as `maturin` to build for multiple versions in a single build, this leads to Python wheels being compiled against the wrong Python API version.

All users who distribute artefacts for multiple Python versions are encouraged to update and rebuild with PyO3 0.23.3. Affected wheels produced from PyO3 0.23.0 through 0.23.2 are highly unstable and will crash the Python interpreter in unpredictable ways.
GitHub Security Advisory: GHSA-gw5w-5j7f-jmjj
Package: pprof (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 0.14.0
Patched in: 0.14.0

Summary: Unsound usages of `std::slice::from_raw_parts` 

Details:
The library breaks the safety assumptions when using unsafe API `std::slice::from_raw_parts`. First, when using the API in iterator implementation (`TempFdArrayIterator.next`), generic type could be any type, which would create and pass a misaligned pointer to the unsafe API. Second, when validating the address, the code passed the type `c_void`, which could also be any type, leading to potential uninitialized memory exposure.  

Two unsound usages here highlight the necessity for developers to perform type checks before doing type conversion with unsafe API.  

The panic caused by the misalignment causes several downstream applications (e.g., `greptimedb`) to crash when using `pprof::report::ReportBuilder::build`.  

This was patched in 0.14.0.  

The developer also suggested moving to [pprof2](https://crates.io/crates/pprof2).
GitHub Security Advisory: GHSA-4grw-m28r-q285
Package: pgp (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.14.2
Patched in: 0.14.2

Summary: rPGP Potential Resource Exhaustion when handling Untrusted Messages

Details:
During a security audit, [Radically Open Security](https://www.radicallyopensecurity.com/) discovered two vulnerabilities which allow attackers to trigger resource exhaustion vulnerabilities in `rpgp` by providing crafted messages. This affects general message parsing and decryption with symmetric keys.

### Impact
Affected `rpgp` versions do not correctly set upper limits on the total reserved amount of memory when parsing long sequences of partial OpenPGP packets, which can grow to to several GiB in size. Additionally, up to 4GiB of memory is reserved for OpenPGP packets of fixed size with large length fields, even if less data is received. 
Depending on existing message size restrictions and available system resources, this can cause out-of-memory conditions and crash the `rpgp` process or cause other system instability through memory resource exhaustion when parsing crafted messages.

Affected `rpgp` versions are susceptible to excessive memory allocation with values of up to 2TiB or long processing times for some decryption operations which involve the [Argon2 function](https://datatracker.ietf.org/doc/html/rfc9580.html#name-argon2). An attacker can provide a valid `Symmetric Key Encrypted Session Key` packet (SKESK) which uses `Argon2` for String-to-Key hashing with parameters that are excessive, but within specification limits of the RFC9580 OpenPGP standard. Since `rpgp` did not further restrict the Argon2 parameters, this can cause out-of-memory conditions and crash the `rpgp` process. Under some conditions,   the memory resource exhaustion may trigger other system instability. Alternatively, this can make the program unresponsive via long computations. The attacker needs to trick a victim into attempting decryption, but does not require knowledge of the symmetric secret used by the victim.

There is no impact to confidentiality or integrity security properties.

### Versions and Patches

The impact details on the message parsing component varies with different versions. We've confirmed some of the problematic behavior on older versions such as `v0.10.0` and see all recent versions as affected in some form.  

The affected `Argon2` functionality was introduced with `v0.12.0-alpha.1`, earlier versions are not vulnerable.

The vulnerabilities have been fixed with version `0.14.2`. We recommend all users to upgrade to this version.

### References


The security audit was made possible by the [NLnet Foundation NGI Zero Core](https://nlnet.nl/core/) grant program [for rpgp](https://nlnet.nl/project/rPGP-cryptorefresh/).
GitHub Security Advisory: GHSA-9rmp-2568-59rv
Package: pgp (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-130: Improper Handling of Length Parameter Inconsistency, CWE-248: Uncaught Exception, CWE-617: Reachable Assertion
Vulnerable versions: < 0.14.1
Patched in: 0.14.1

Summary: rPGP Panics on Malformed Untrusted Input

Details:
During a security audit, [Radically Open Security](https://www.radicallyopensecurity.com/) discovered several reachable edge cases which allow an attacker to trigger `rpgp` crashes by providing crafted data.

### Impact
When processing malformed input, `rpgp` can run into Rust panics which halt the program.

This can happen in the following scenarios:
* Parsing OpenPGP messages from binary or armor format
* Decrypting OpenPGP messages via `decrypt_with_password()`
* Parsing or converting public keys
* Parsing signed cleartext messages from armor format
* Using malformed private keys to sign or encrypt

Given the affected components, we consider most attack vectors to be reachable by remote attackers during typical use cases of the `rpgp` library. The attack complexity is low since the malformed messages are generic, short, and require no victim-specific knowledge.

The result is a denial-of-service impact via program termination. There is no impact to confidentiality or integrity security properties.

### Versions and Patches
All recent versions are affected by at least some of the above mentioned issues. 

The vulnerabilities have been fixed with version `0.14.1`. We recommend all users to upgrade to this version.

### References


The security audit was made possible by the [NLnet Foundation NGI Zero Core](https://nlnet.nl/core/) grant program [for rpgp](https://nlnet.nl/project/rPGP-cryptorefresh/).