error[vulnerability]: Integer overflow in `BytesMut::reserve`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:49:1
   │
49 │ bytes 1.8.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0007
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0007
   ├ In the unique reclaim path of `BytesMut::reserve`, the condition
     ```rs
     if v_capacity >= new_cap + offset
     ```
     uses an unchecked addition. When `new_cap + offset` overflows `usize` in release builds, this condition may incorrectly pass, causing `self.cap` to be set to a value that exceeds the actual allocated capacity. Subsequent APIs such as `spare_capacity_mut()` then trust this corrupted `cap` value and may create out-of-bounds slices, leading to UB.
     
     This behavior is observable in release builds (integer overflow wraps), whereas debug builds panic due to overflow checks.
     
     ## PoC
     
     ```rs
     use bytes::*;
     
     fn main() {
         let mut a = BytesMut::from(&b"hello world"[..]);
         let mut b = a.split_off(5);
     
         // Ensure b becomes the unique owner of the backing storage
         drop(a);
     
         // Trigger overflow in new_cap + offset inside reserve
         b.reserve(usize::MAX - 6);
     
         // This call relies on the corrupted cap and may cause UB & HBO
         b.put_u8(b'h');
     }
     ```
     
     # Workarounds
     
     Users of `BytesMut::reserve` are only affected if integer overflow checks are configured to wrap. When integer overflow is configured to panic, this issue does not apply.
   ├ Announcement: https://github.com/advisories/GHSA-434x-w66g-qw3r
   ├ Solution: Upgrade to >=1.11.1 (try `cargo update -p bytes`)
   ├ bytes v1.8.0
     ├── h2 v0.4.6
     │   └── hyper v1.6.0
     │       ├── httpmock v0.8.0-alpha.1
     │       │   └── libdd-trace-utils v1.0.0
     │       │       └── (dev) libdd-trace-utils v1.0.0 (*)
     │       ├── hyper-rustls v0.27.3
     │       │   └── libdd-common v1.1.0
     │       │       └── libdd-trace-utils v1.0.0 (*)
     │       ├── hyper-util v0.1.17
     │       │   ├── httpmock v0.8.0-alpha.1 (*)
     │       │   ├── hyper-rustls v0.27.3 (*)
     │       │   └── libdd-common v1.1.0 (*)
     │       ├── libdd-common v1.1.0 (*)
     │       └── libdd-trace-utils v1.0.0 (*)
     ├── headers v0.4.0
     │   └── httpmock v0.8.0-alpha.1 (*)
     ├── http v1.1.0
     │   ├── h2 v0.4.6 (*)
     │   ├── headers v0.4.0 (*)
     │   ├── headers-core v0.3.0
     │   │   └── headers v0.4.0 (*)
     │   ├── http-body v1.0.1
     │   │   ├── http-body-util v0.1.2
     │   │   │   ├── httpmock v0.8.0-alpha.1 (*)
     │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   └── libdd-trace-utils v1.0.0 (*)
     │   │   ├── hyper v1.6.0 (*)
     │   │   ├── hyper-util v0.1.17 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   ├── http-body-util v0.1.2 (*)
     │   ├── httpmock v0.8.0-alpha.1 (*)
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── libdd-common v1.1.0 (*)
     │   └── libdd-trace-utils v1.0.0 (*)
     ├── http-body v1.0.1 (*)
     ├── http-body-util v0.1.2 (*)
     ├── httpmock v0.8.0-alpha.1 (*)
     ├── hyper v1.6.0 (*)
     ├── hyper-util v0.1.17 (*)
     ├── libdd-trace-utils v1.0.0 (*)
     ├── prost v0.14.3
     │   ├── libdd-trace-protobuf v1.0.0
     │   │   ├── libdd-trace-normalization v1.0.0
     │   │   │   └── libdd-trace-utils v1.0.0 (*)
     │   │   └── libdd-trace-utils v1.0.0 (*)
     │   └── libdd-trace-utils v1.0.0 (*)
     ├── tokio v1.49.0
     │   ├── h2 v0.4.6 (*)
     │   ├── httpmock v0.8.0-alpha.1 (*)
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── (dev) libdd-common v1.1.0 (*)
     │   ├── (dev) libdd-trace-protobuf v1.0.0 (*)
     │   ├── (dev) libdd-trace-utils v1.0.0 (*)
     │   ├── tokio-rustls v0.26.0
     │   │   ├── hyper-rustls v0.27.3 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   └── tokio-util v0.7.12
     │       └── h2 v0.4.6 (*)
     └── tokio-util v0.7.12 (*)

error[vulnerability]: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:132:1
    │
132 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2021-0078
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0078
    ├ `hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers.
      Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error.
      
      To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents
      but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-f3pg-qwvg-p99c
    ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
    ├ hyper v0.10.16
      ├── iron v0.6.1
      │   └── multipart v0.18.0
      │       └── (dev) libdd-common v1.1.0
      │           └── libdd-trace-utils v1.0.0
      │               └── (dev) libdd-trace-utils v1.0.0 (*)
      ├── multipart v0.18.0 (*)
      └── nickel v0.11.0
          └── multipart v0.18.0 (*)

error[vulnerability]: Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data loss
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:132:1
    │
132 │ hyper 0.10.16 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2021-0079
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2021-0079
    ├ When decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation,
      this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack.
      
      To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send
      requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible,
      any upstream proxies must accept a chunk size greater than 64 bits.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-5h46-h7hh-c6x9
    ├ Solution: Upgrade to >=0.14.10 (try `cargo update -p hyper`)
    ├ hyper v0.10.16
      ├── iron v0.6.1
      │   └── multipart v0.18.0
      │       └── (dev) libdd-common v1.1.0
      │           └── libdd-trace-utils v1.0.0
      │               └── (dev) libdd-trace-utils v1.0.0 (*)
      ├── multipart v0.18.0 (*)
      └── nickel v0.11.0
          └── multipart v0.18.0 (*)

error[vulnerability]: `idna` accepts Punycode labels that do not produce any non-ASCII when decoded
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:148:1
    │
148 │ idna 0.1.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2024-0421
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0421
    ├ `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.
    ├ Announcement: https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
    ├ Solution: Upgrade to >=1.0.0 (try `cargo update -p idna`)
    ├ idna v0.1.5
      └── url v1.7.2
          ├── hyper v0.10.16
          │   ├── iron v0.6.1
          │   │   └── multipart v0.18.0
          │   │       └── (dev) libdd-common v1.1.0
          │   │           └── libdd-trace-utils v1.0.0
          │   │               └── (dev) libdd-trace-utils v1.0.0 (*)
          │   ├── multipart v0.18.0 (*)
          │   └── nickel v0.11.0
          │       └── multipart v0.18.0 (*)
          ├── iron v0.6.1 (*)
          ├── nickel v0.11.0 (*)
          └── tiny_http v0.6.4
              └── multipart v0.18.0 (*)

error[unmaintained]: multipart is Unmaintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:186:1
    │
186 │ multipart 0.18.0 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2023-0050
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2023-0050
    ├ The `multipart` crate is unmaintained. The author has archived the github
      repository.
      
      Alternatives:
      
      - [multer](https://crates.io/crates/multer)
      - [multiparty](https://crates.io/crates/multiparty)
    ├ Solution: No safe upgrade is available!
    ├ multipart v0.18.0
      └── (dev) libdd-common v1.1.0
          └── libdd-trace-utils v1.0.0
              └── (dev) libdd-trace-utils v1.0.0 (*)

error[vulnerability]: Potential segfault in the time crate
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:301:1
    │
301 │ time 0.1.45 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2020-0071
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2020-0071
    ├ ### Impact
      
      The affected functions set environment variables without synchronization. On Unix-like operating systems, this can crash in multithreaded programs. Programs may segfault due to dereferencing a dangling pointer if an environment variable is read in a different thread than the affected functions. This may occur without the user's knowledge, notably in the Rust standard library or third-party libraries.
      
      The affected functions from time 0.2.7 through 0.2.22 are:
      
      - `time::UtcOffset::local_offset_at`
      - `time::UtcOffset::try_local_offset_at`
      - `time::UtcOffset::current_local_offset`
      - `time::UtcOffset::try_current_local_offset`
      - `time::OffsetDateTime::now_local`
      - `time::OffsetDateTime::try_now_local`
      
      The affected functions in time 0.1 (all versions) are:
      
      - `time::at_utc`
      - `time::at`
      - `time::now`
      - `time::tzset`
      
      Non-Unix targets (including Windows and wasm) are unaffected.
      
      ### Patches
      
      Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods.
      
      Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code.
      
      Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.
      
      ### Workarounds
      
      A possible workaround for crates affected through the transitive dependency in `chrono`, is to avoid using the default `oldtime` feature dependency of the `chrono` crate by disabling its `default-features` and manually specifying the required features instead.
      
      #### Examples:
      
      `Cargo.toml`:  
      
      ```toml
      chrono = { version = "0.4", default-features = false, features = ["serde"] }
      ```
      
      ```toml
      chrono = { version = "0.4.22", default-features = false, features = ["clock"] }
      ```
      
      Commandline:  
      
      ```bash
      cargo add chrono --no-default-features -F clock
      ```
      
      Sources:  
       - [chronotope/chrono#602 (comment)](https://github.com/chronotope/chrono/issues/602#issuecomment-1242149249)  
       - [vityafx/serde-aux#21](https://github.com/vityafx/serde-aux/issues/21)
    ├ Announcement: https://github.com/time-rs/time/issues/293
    ├ Solution: Upgrade to >=0.2.23 (try `cargo update -p time`)
    ├ time v0.1.45
      ├── hyper v0.10.16
      │   ├── iron v0.6.1
      │   │   └── multipart v0.18.0
      │   │       └── (dev) libdd-common v1.1.0
      │   │           └── libdd-trace-utils v1.0.0
      │   │               └── (dev) libdd-trace-utils v1.0.0 (*)
      │   ├── multipart v0.18.0 (*)
      │   └── nickel v0.11.0
      │       └── multipart v0.18.0 (*)
      └── nickel v0.11.0 (*)

advisories FAILED, bans ok, sources ok