error[vulnerability]: Integer overflow in `BytesMut::reserve`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:26:1
   │
26 │ 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
     ├── http v1.1.0
     │   ├── http-body v1.0.1
     │   │   ├── http-body-util v0.1.2
     │   │   │   ├── libdd-common v1.1.0
     │   │   │   │   ├── (build) libdd-crashtracker v1.0.0
     │   │   │   │   └── libdd-telemetry v2.0.0
     │   │   │   │       └── libdd-crashtracker v1.0.0 (*)
     │   │   │   └── libdd-telemetry v2.0.0 (*)
     │   │   ├── hyper v1.6.0
     │   │   │   ├── hyper-rustls v0.27.3
     │   │   │   │   └── libdd-common v1.1.0 (*)
     │   │   │   ├── hyper-util v0.1.17
     │   │   │   │   ├── hyper-rustls v0.27.3 (*)
     │   │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   │   └── libdd-telemetry v2.0.0 (*)
     │   │   │   ├── libdd-common v1.1.0 (*)
     │   │   │   └── libdd-telemetry v2.0.0 (*)
     │   │   ├── hyper-util v0.1.17 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   ├── http-body-util v0.1.2 (*)
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── libdd-common v1.1.0 (*)
     │   ├── libdd-crashtracker v1.0.0 (*)
     │   └── libdd-telemetry v2.0.0 (*)
     ├── http-body v1.0.1 (*)
     ├── http-body-util v0.1.2 (*)
     ├── hyper v1.6.0 (*)
     ├── hyper-util v0.1.17 (*)
     ├── prost v0.14.3
     │   └── libdd-ddsketch v1.0.0
     │       └── libdd-telemetry v2.0.0 (*)
     ├── tokio v1.49.0
     │   ├── hyper v1.6.0 (*)
     │   ├── hyper-rustls v0.27.3 (*)
     │   ├── hyper-util v0.1.17 (*)
     │   ├── (dev) libdd-common v1.1.0 (*)
     │   ├── libdd-crashtracker v1.0.0 (*)
     │   ├── (dev) libdd-telemetry v2.0.0 (*)
     │   ├── tokio-rustls v0.26.0
     │   │   ├── hyper-rustls v0.27.3 (*)
     │   │   └── libdd-common v1.1.0 (*)
     │   └── tokio-util v0.7.12
     │       └── libdd-telemetry v2.0.0 (*)
     └── 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:93:1
   │
93 │ 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
     │           ├── (build) libdd-crashtracker v1.0.0
     │           └── libdd-telemetry v2.0.0
     │               └── libdd-crashtracker 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:93:1
   │
93 │ 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
     │           ├── (build) libdd-crashtracker v1.0.0
     │           └── libdd-telemetry v2.0.0
     │               └── libdd-crashtracker 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:99:1
   │
99 │ 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
         │   │           ├── (build) libdd-crashtracker v1.0.0
         │   │           └── libdd-telemetry v2.0.0
         │   │               └── libdd-crashtracker 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:135:1
    │
135 │ 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
          ├── (build) libdd-crashtracker v1.0.0
          └── libdd-telemetry v2.0.0
              └── libdd-crashtracker v1.0.0 (*)

error[vulnerability]: Potential segfault in the time crate
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:250:1
    │
250 │ 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
      │   │           ├── (build) libdd-crashtracker v1.0.0
      │   │           └── libdd-telemetry v2.0.0
      │   │               └── libdd-crashtracker v1.0.0 (*)
      │   ├── multipart v0.18.0 (*)
      │   └── nickel v0.11.0
      │       └── multipart v0.18.0 (*)
      └── nickel v0.11.0 (*)

error[vulnerability]: Logging user input may result in poisoning logs with ANSI escape sequences
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:263:1
    │
263 │ tracing-subscriber 0.3.19 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2025-0055
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0055
    ├ Previous versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:
      
      - Manipulate terminal title bars
      - Clear screens or modify terminal display
      - Potentially mislead users through terminal manipulation
      
      In isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.
      
      This was patched in [PR #3368](https://github.com/tokio-rs/tracing/pull/3368) to escape ANSI control characters from user input.
    ├ Announcement: https://github.com/advisories/GHSA-xwfj-jgwm-7wp5
    ├ Solution: Upgrade to >=0.3.20 (try `cargo update -p tracing-subscriber`)
    ├ tracing-subscriber v0.3.19
      └── (dev) libdd-telemetry v2.0.0
          └── libdd-crashtracker v1.0.0

advisories FAILED, bans ok, sources ok