Skip to content

chore(release): proposal for libdd-live-debugger - #2468

Open
dd-octo-sts[bot] wants to merge 33 commits into
release/libdd-live-debugger/20260904-151348from
release-proposal/libdd-live-debugger/20260904-151348
Open

chore(release): proposal for libdd-live-debugger#2468
dd-octo-sts[bot] wants to merge 33 commits into
release/libdd-live-debugger/20260904-151348from
release-proposal/libdd-live-debugger/20260904-151348

Conversation

@dd-octo-sts

@dd-octo-sts dd-octo-sts Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Release proposal for libdd-live-debugger and its dependencies

This PR contains version bumps based on public API changes and commits since last release.

⚠️ Crates left out of this proposal affected by its major bumps

These publishable workspace crates are not part of this release but their dependency requirement was rewritten on this branch while their published version still requires the old major. If they are a dependency on your deployment not including them in the release could result in duplicate packages or symbol incompatibility.

  • libdd-capabilities-impl 4.0.05.0.0 affects: libdd-crashtracker, libdd-tracer-flare
  • libdd-common 5.2.06.0.0 affects: libdd-crashtracker, libdd-ffe, libdd-http-client, libdd-ipc, libdd-profiling, libdd-sampling, libdd-tracer-flare
  • libdd-remote-config 4.0.05.0.0 affects: libdd-ffe, libdd-tracer-flare
  • libdd-telemetry 7.0.08.0.0 affects: libdd-crashtracker
  • libdd-trace-stats 8.0.09.0.0 affects: libdd-ipc
  • libdd-trace-utils 11.0.012.0.0 affects: libdd-sampling, libdd-tracer-flare

libdd-capabilities

Next version: 3.0.1
Semver bump: patch
Tag: libdd-capabilities-v3.0.1

Commits

libdd-common

Next version: 6.0.0
Semver bump: major
Tag: libdd-common-v6.0.0

Commits

libdd-tinybytes

Next version: 1.1.3
Semver bump: patch
Tag: libdd-tinybytes-v1.1.3

Commits

libdd-capabilities-impl

Next version: 5.0.0
Semver bump: major
Tag: libdd-capabilities-impl-v5.0.0

⚠️ major bump forced due to:

  • libdd-common: ^5.1.1 → ^6.0.0

Commits

libdd-remote-config

Next version: 5.0.0
Semver bump: major
Tag: libdd-remote-config-v5.0.0

⚠️ major bump forced due to:

  • libdd-common: ^5.2.0 → ^6.0.0

Commits

libdd-shared-runtime

Next version: 4.0.0
Semver bump: major
Tag: libdd-shared-runtime-v4.0.0

⚠️ major bump forced due to:

  • libdd-common: ^5.2.0 → ^6.0.0

Commits

libdd-trace-utils

Next version: 12.0.0
Semver bump: major
Tag: libdd-trace-utils-v12.0.0

⚠️ major bump forced due to:

  • libdd-common: ^5.2.0 → ^6.0.0

Commits

libdd-dogstatsd-client

Next version: 6.0.0
Semver bump: major
Tag: libdd-dogstatsd-client-v6.0.0

⚠️ major bump forced due to:

  • libdd-common: ^5.2.0 → ^6.0.0

Commits

libdd-telemetry

Next version: 8.0.0
Semver bump: major
Tag: libdd-telemetry-v8.0.0

⚠️ major bump forced due to:

  • libdd-common: ^5.2.0 → ^6.0.0

Commits

libdd-trace-obfuscation

Next version: 8.0.0
Semver bump: major
Tag: libdd-trace-obfuscation-v8.0.0

⚠️ major bump forced due to:

  • libdd-common: ^5.2.0 → ^6.0.0
  • libdd-trace-utils: ^11.0.0 → ^12.0.0

Commits

libdd-data-pipeline-core

Next version: 1.0.0
Semver bump: major
Tag: libdd-data-pipeline-core-v1.0.0

Warning: this is an initial release. Please verify that the version and commits included are correct.

libdd-trace-stats

Next version: 9.0.0
Semver bump: major
Tag: libdd-trace-stats-v9.0.0

⚠️ major bump forced due to:

  • libdd-common: ^5.2.0 → ^6.0.0
  • libdd-trace-obfuscation: ^7.0.0 → ^8.0.0
  • libdd-trace-utils: ^11.0.0 → ^12.0.0

Commits

libdd-data-pipeline

Next version: 10.0.0
Semver bump: major
Tag: libdd-data-pipeline-v10.0.0

⚠️ major bump forced due to:

  • libdd-common: ^5.2.0 → ^6.0.0
  • libdd-trace-obfuscation: ^7.0.0 → ^8.0.0
  • libdd-trace-stats: ^8.0.0 → ^9.0.0
  • libdd-trace-utils: ^11.0.0 → ^12.0.0

Commits

libdd-live-debugger

Next version: 1.0.0
Semver bump: major
Tag: libdd-live-debugger-v1.0.0

Warning: this is an initial release. Please verify that the version and commits included are correct.

github-actions Bot and others added 30 commits September 4, 2026 15:46
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
… bumps

Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
…bumps

Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
github-actions Bot and others added 2 commits September 4, 2026 15:47
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
Co-authored-by: hoolioh <107922352+hoolioh@users.noreply.github.com>
@github-actions

github-actions Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

⚠️ 77 issue(s) found, showing only errors (advisories, bans, sources)

📦 datadog-sidecar - 6 error(s)

Show output
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:36:1
   │
36 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     ├── datadog-sidecar v0.0.1
     ├── (dev) libdd-ffe v1.0.0
     │   └── datadog-sidecar v0.0.1 (*)
     └── libdd-ipc v1.0.0
         └── datadog-sidecar v0.0.1 (*)

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:91:1
   │
91 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v6.0.0
                     │   ├── datadog-sidecar v0.0.1
                     │   ├── libdd-capabilities-impl v5.0.0
                     │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-crashtracker v2.0.1
                     │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   └── libdd-crashtracker-ffi v43.0.0
                     │   │   │       └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-data-pipeline v10.0.0
                     │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   └── libdd-live-debugger v1.0.0
                     │   │   │       └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── (dev) libdd-ffe v1.0.0
                     │   │   │   └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-live-debugger v1.0.0 (*)
                     │   │   ├── libdd-remote-config v5.0.0
                     │   │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
                     │   │   │   ├── libdd-ffe v1.0.0 (*)
                     │   │   │   ├── libdd-live-debugger v1.0.0 (*)
                     │   │   │   └── (dev) libdd-remote-config v5.0.0 (*)
                     │   │   ├── libdd-shared-runtime v4.0.0
                     │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v6.0.0
                     │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v9.0.0
                     │   │   │   │       ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │       ├── libdd-data-pipeline v10.0.0 (*)
                     │   │   │   │       └── libdd-ipc v1.0.0
                     │   │   │   │           └── datadog-sidecar v0.0.1 (*)
                     │   │   │   ├── libdd-telemetry v8.0.0
                     │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │   ├── libdd-crashtracker v2.0.1 (*)
                     │   │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v9.0.0 (*)
                     │   │   │   └── libdd-trace-stats v9.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v8.0.0 (*)
                     │   │   ├── libdd-trace-stats v9.0.0 (*)
                     │   │   └── libdd-trace-utils v12.0.0
                     │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
                     │   │       ├── libdd-data-pipeline v10.0.0 (*)
                     │   │       ├── libdd-data-pipeline-core v1.0.0
                     │   │       │   └── libdd-data-pipeline v10.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v8.0.0
                     │   │       │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   │       │   └── libdd-trace-stats v9.0.0 (*)
                     │   │       ├── libdd-trace-stats v9.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v12.0.0 (*)
                     │   ├── libdd-common-ffi v43.0.0
                     │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   └── libdd-crashtracker-ffi v43.0.0 (*)
                     │   ├── (build) libdd-crashtracker v2.0.1 (*)
                     │   ├── libdd-crashtracker-ffi v43.0.0 (*)
                     │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   ├── libdd-dogstatsd-client v6.0.0 (*)
                     │   ├── libdd-ffe v1.0.0 (*)
                     │   ├── libdd-ipc v1.0.0 (*)
                     │   ├── libdd-live-debugger v1.0.0 (*)
                     │   ├── libdd-remote-config v5.0.0 (*)
                     │   ├── libdd-shared-runtime v4.0.0 (*)
                     │   ├── libdd-telemetry v8.0.0 (*)
                     │   ├── libdd-trace-obfuscation v8.0.0 (*)
                     │   ├── libdd-trace-stats v9.0.0 (*)
                     │   └── libdd-trace-utils v12.0.0 (*)
                     ├── (dev) libdd-crashtracker v2.0.1 (*)
                     ├── (dev) libdd-data-pipeline v10.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   ├── libdd-ipc v1.0.0 (*)
                     │   ├── libdd-telemetry v8.0.0 (*)
                     │   └── libdd-trace-stats v9.0.0 (*)
                     ├── (dev) libdd-ipc v1.0.0 (*)
                     ├── (dev) libdd-trace-normalization v4.0.0
                     │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   └── libdd-trace-utils v12.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v8.0.0 (*)
                     ├── (dev) libdd-trace-stats v9.0.0 (*)
                     └── (dev) libdd-trace-utils v12.0.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:152:1
    │
152 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0258
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
    ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
      If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
      
      Low severity.
      
      Patched in v0.4.16.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
    ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
    ├ h2 v0.4.6
      ├── hyper v1.6.0
      │   ├── httpmock v0.8.0-alpha.1
      │   │   ├── (dev) datadog-sidecar v0.0.1
      │   │   ├── (dev) libdd-data-pipeline v10.0.0
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   └── libdd-live-debugger v1.0.0
      │   │   │       └── datadog-sidecar v0.0.1 (*)
      │   │   ├── (dev) libdd-ffe v1.0.0
      │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   ├── (dev) libdd-telemetry v8.0.0
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   ├── libdd-crashtracker v2.0.1
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   └── libdd-crashtracker-ffi v43.0.0
      │   │   │   │       └── datadog-sidecar v0.0.1 (*)
      │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │   │   └── libdd-trace-stats v9.0.0
      │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │       ├── libdd-data-pipeline v10.0.0 (*)
      │   │   │       └── libdd-ipc v1.0.0
      │   │   │           └── datadog-sidecar v0.0.1 (*)
      │   │   ├── (dev) libdd-trace-stats v9.0.0 (*)
      │   │   └── libdd-trace-utils v12.0.0
      │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       ├── libdd-data-pipeline v10.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       │   └── libdd-data-pipeline v10.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v8.0.0
      │   │       │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       │   └── libdd-trace-stats v9.0.0 (*)
      │   │       ├── libdd-trace-stats v9.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v12.0.0 (*)
      │   ├── hyper-rustls v0.27.7
      │   │   └── libdd-common v6.0.0
      │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │       ├── libdd-capabilities-impl v5.0.0
      │   │       │   ├── datadog-sidecar v0.0.1 (*)
      │   │       │   ├── libdd-crashtracker v2.0.1 (*)
      │   │       │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │       │   ├── (dev) libdd-ffe v1.0.0 (*)
      │   │       │   ├── libdd-live-debugger v1.0.0 (*)
      │   │       │   ├── libdd-remote-config v5.0.0
      │   │       │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       │   │   ├── libdd-ffe v1.0.0 (*)
      │   │       │   │   ├── libdd-live-debugger v1.0.0 (*)
      │   │       │   │   └── (dev) libdd-remote-config v5.0.0 (*)
      │   │       │   ├── libdd-shared-runtime v4.0.0
      │   │       │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │       │   │   ├── libdd-dogstatsd-client v6.0.0
      │   │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │       │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │       │   │   │   └── libdd-trace-stats v9.0.0 (*)
      │   │       │   │   ├── libdd-telemetry v8.0.0 (*)
      │   │       │   │   └── libdd-trace-stats v9.0.0 (*)
      │   │       │   ├── (dev) libdd-telemetry v8.0.0 (*)
      │   │       │   ├── libdd-trace-stats v9.0.0 (*)
      │   │       │   └── libdd-trace-utils v12.0.0 (*)
      │   │       ├── libdd-common-ffi v43.0.0
      │   │       │   ├── datadog-sidecar v0.0.1 (*)
      │   │       │   └── libdd-crashtracker-ffi v43.0.0 (*)
      │   │       ├── (build) libdd-crashtracker v2.0.1 (*)
      │   │       ├── libdd-crashtracker-ffi v43.0.0 (*)
      │   │       ├── libdd-data-pipeline v10.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       ├── libdd-dogstatsd-client v6.0.0 (*)
      │   │       ├── libdd-ffe v1.0.0 (*)
      │   │       ├── libdd-ipc v1.0.0 (*)
      │   │       ├── libdd-live-debugger v1.0.0 (*)
      │   │       ├── libdd-remote-config v5.0.0 (*)
      │   │       ├── libdd-shared-runtime v4.0.0 (*)
      │   │       ├── libdd-telemetry v8.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v8.0.0 (*)
      │   │       ├── libdd-trace-stats v9.0.0 (*)
      │   │       └── libdd-trace-utils v12.0.0 (*)
      │   ├── hyper-util v0.1.17
      │   │   ├── httpmock v0.8.0-alpha.1 (*)
      │   │   ├── hyper-rustls v0.27.7 (*)
      │   │   ├── libdd-common v6.0.0 (*)
      │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │   └── libdd-remote-config v5.0.0 (*)
      │   ├── libdd-common v6.0.0 (*)
      │   ├── libdd-common-ffi v43.0.0 (*)
      │   ├── libdd-data-pipeline v10.0.0 (*)
      │   ├── libdd-remote-config v5.0.0 (*)
      │   └── libdd-trace-utils v12.0.0 (*)
      └── (dev) libdd-data-pipeline v10.0.0 (*)

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:234:1
    │
234 │ lru 0.16.4 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0253
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0253
    ├ `LruCache::pop()` in `lru` was not panic-safe. If the `Drop` implementation of a stored key panics during `pop()`, `self.detach()` is never called, leaving dangling pointers in the internal doubly-linked list.
      
      A subsequent cache operation that triggers eviction can then dereference these dangling pointers:
      - The node is freed from the map, but remains linked in the LRU list due to the skipped `detach()` call
      - When a new insertion causes eviction, the LRU traversal encounters the dangling pointer
      - This results in a write to already-freed memory during the eviction process
      
      ## Impact
      
      - **CWE-416 (Use-After-Free):** memory corruption when subsequent cache operations access freed node pointers in the linked list
      - **CWE-415 (Double Free):** potential heap corruption when the same memory is freed multiple times
      
      Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used with key types that have potentially-panicking `Drop` implementations.
      
      ## Fix
      
      Fixed in `lru` 0.18.2 by detaching the node from the linked list before freeing it and dropping the key ([lru-rs#238](https://github.com/jeromefroe/lru-rs/pull/238)).
    ├ Announcement: https://github.com/jeromefroe/lru-rs/pull/238
    ├ Solution: Upgrade to >=0.18.2 (try `cargo update -p lru`)
    ├ lru v0.16.4
      └── libdd-ffe v1.0.0
          └── datadog-sidecar v0.0.1

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:309:1
    │
309 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── datadog-sidecar v0.0.1
      ├── libdd-common v6.0.0
      │   ├── datadog-sidecar v0.0.1 (*)
      │   ├── libdd-capabilities-impl v5.0.0
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-crashtracker v2.0.1
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   └── libdd-crashtracker-ffi v43.0.0
      │   │   │       └── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-data-pipeline v10.0.0
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   └── libdd-live-debugger v1.0.0
      │   │   │       └── datadog-sidecar v0.0.1 (*)
      │   │   ├── (dev) libdd-ffe v1.0.0
      │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-live-debugger v1.0.0 (*)
      │   │   ├── libdd-remote-config v5.0.0
      │   │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │   │   ├── libdd-ffe v1.0.0 (*)
      │   │   │   ├── libdd-live-debugger v1.0.0 (*)
      │   │   │   └── (dev) libdd-remote-config v5.0.0 (*)
      │   │   ├── libdd-shared-runtime v4.0.0
      │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │   │   ├── libdd-dogstatsd-client v6.0.0
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v9.0.0
      │   │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │       ├── libdd-data-pipeline v10.0.0 (*)
      │   │   │   │       └── libdd-ipc v1.0.0
      │   │   │   │           └── datadog-sidecar v0.0.1 (*)
      │   │   │   ├── libdd-telemetry v8.0.0
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   ├── libdd-crashtracker v2.0.1 (*)
      │   │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v9.0.0 (*)
      │   │   │   └── libdd-trace-stats v9.0.0 (*)
      │   │   ├── (dev) libdd-telemetry v8.0.0 (*)
      │   │   ├── libdd-trace-stats v9.0.0 (*)
      │   │   └── libdd-trace-utils v12.0.0
      │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       ├── libdd-data-pipeline v10.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       │   └── libdd-data-pipeline v10.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v8.0.0
      │   │       │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       │   └── libdd-trace-stats v9.0.0 (*)
      │   │       ├── libdd-trace-stats v9.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v12.0.0 (*)
      │   ├── libdd-common-ffi v43.0.0
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   └── libdd-crashtracker-ffi v43.0.0 (*)
      │   ├── (build) libdd-crashtracker v2.0.1 (*)
      │   ├── libdd-crashtracker-ffi v43.0.0 (*)
      │   ├── libdd-data-pipeline v10.0.0 (*)
      │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   ├── libdd-dogstatsd-client v6.0.0 (*)
      │   ├── libdd-ffe v1.0.0 (*)
      │   ├── libdd-ipc v1.0.0 (*)
      │   ├── libdd-live-debugger v1.0.0 (*)
      │   ├── libdd-remote-config v5.0.0 (*)
      │   ├── libdd-shared-runtime v4.0.0 (*)
      │   ├── libdd-telemetry v8.0.0 (*)
      │   ├── libdd-trace-obfuscation v8.0.0 (*)
      │   ├── libdd-trace-stats v9.0.0 (*)
      │   └── libdd-trace-utils v12.0.0 (*)
      ├── libdd-crashtracker v2.0.1 (*)
      ├── (dev) libdd-data-pipeline v10.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.1
      │   ├── libdd-data-pipeline v10.0.0 (*)
      │   ├── libdd-ipc v1.0.0 (*)
      │   ├── libdd-telemetry v8.0.0 (*)
      │   └── libdd-trace-stats v9.0.0 (*)
      ├── (dev) libdd-trace-normalization v4.0.0
      │   ├── libdd-data-pipeline v10.0.0 (*)
      │   └── libdd-trace-utils v12.0.0 (*)
      ├── (dev) libdd-trace-stats v9.0.0 (*)
      ├── libdd-trace-utils v12.0.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v6.0.0 (*)
          └── (dev) libdd-tinybytes v1.1.3
              ├── datadog-sidecar v0.0.1 (*)
              ├── libdd-data-pipeline v10.0.0 (*)
              ├── (dev) libdd-data-pipeline-core v1.0.0 (*)
              ├── libdd-ipc v1.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.3 (*)
              ├── (dev) libdd-trace-obfuscation v8.0.0 (*)
              └── libdd-trace-utils v12.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:404:1
    │
404 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      ├── libdd-remote-config v5.0.0
      │   ├── (dev) datadog-sidecar v0.0.1
      │   ├── libdd-ffe v1.0.0
      │   │   └── datadog-sidecar v0.0.1 (*)
      │   ├── libdd-live-debugger v1.0.0
      │   │   └── datadog-sidecar v0.0.1 (*)
      │   └── (dev) libdd-remote-config v5.0.0 (*)
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v10.0.0
                  ├── datadog-sidecar v0.0.1 (*)
                  └── libdd-live-debugger v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-agent-client - 5 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:43:1
   │
43 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 └── libdd-http-client v1.0.0
                     └── libdd-agent-client v43.0.0

error[vulnerability]: h2 unbounded empty DATA frames
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:76:1
   │
76 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0258
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
   ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
     If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
     
     Low severity.
     
     Patched in v0.4.16.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
   ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
   ├ h2 v0.4.6
     └── hyper v1.6.0
         ├── httpmock v0.8.0-alpha.1
         │   ├── (dev) libdd-agent-client v43.0.0
         │   └── (dev) libdd-http-client v1.0.0
         │       └── libdd-agent-client v43.0.0 (*)
         ├── hyper-rustls v0.27.7
         │   └── reqwest v0.13.2
         │       └── libdd-http-client v1.0.0 (*)
         ├── hyper-util v0.1.17
         │   ├── httpmock v0.8.0-alpha.1 (*)
         │   ├── hyper-rustls v0.27.7 (*)
         │   └── reqwest v0.13.2 (*)
         └── reqwest v0.13.2 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:84:1
   │
84 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-http-client v1.0.0
                 └── libdd-agent-client v43.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:84:1
   │
84 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-http-client v1.0.0
                 └── libdd-agent-client v43.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:156:1
    │
156 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── (dev) libdd-common v6.0.0
      │   └── libdd-agent-client v43.0.0
      └── proptest v1.5.0
          └── (dev) libdd-common v6.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-capabilities-impl - 1 error(s)

Show output
error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:74:1
   │
74 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     ├── (dev) libdd-common v6.0.0
     │   └── libdd-capabilities-impl v5.0.0
     └── proptest v1.5.0
         └── (dev) libdd-common v6.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-capabilities - ✅ No issues

📦 libdd-common - 4 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:35:1
   │
35 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     ├── crossbeam-deque v0.8.5
     │   └── rayon-core v1.12.1
     │       └── rayon v1.10.0
     │           └── criterion v0.5.1
     │               └── libdd-common v6.0.0
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 └── libdd-common v6.0.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v6.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:65:1
   │
65 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v6.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:131:1
    │
131 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v6.0.0
      └── proptest v1.5.0
          └── (dev) libdd-common v6.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-crashtracker - 3 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:60:1
   │
60 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── (dev) libdd-crashtracker v2.0.1
                     └── (dev) libdd-ddsketch v1.1.1
                         └── libdd-telemetry v8.0.0
                             └── libdd-crashtracker v2.0.1 (*)

error[vulnerability]: h2 unbounded empty DATA frames
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:98:1
   │
98 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0258
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
   ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
     If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
     
     Low severity.
     
     Patched in v0.4.16.
   ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
   ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
   ├ h2 v0.4.6
     └── hyper v1.6.0
         ├── httpmock v0.8.0-alpha.1
         │   └── (dev) libdd-telemetry v8.0.0
         │       └── libdd-crashtracker v2.0.1
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v6.0.0
         │       ├── libdd-capabilities-impl v5.0.0
         │       │   ├── libdd-crashtracker v2.0.1 (*)
         │       │   ├── libdd-shared-runtime v4.0.0
         │       │   │   └── libdd-telemetry v8.0.0 (*)
         │       │   └── (dev) libdd-telemetry v8.0.0 (*)
         │       ├── (build) libdd-crashtracker v2.0.1 (*)
         │       ├── libdd-shared-runtime v4.0.0 (*)
         │       └── libdd-telemetry v8.0.0 (*)
         ├── hyper-util v0.1.17
         │   ├── httpmock v0.8.0-alpha.1 (*)
         │   ├── hyper-rustls v0.27.7 (*)
         │   └── libdd-common v6.0.0 (*)
         └── libdd-common v6.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:209:1
    │
209 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v6.0.0
      │   ├── libdd-capabilities-impl v5.0.0
      │   │   ├── libdd-crashtracker v2.0.1
      │   │   ├── libdd-shared-runtime v4.0.0
      │   │   │   └── libdd-telemetry v8.0.0
      │   │   │       └── libdd-crashtracker v2.0.1 (*)
      │   │   └── (dev) libdd-telemetry v8.0.0 (*)
      │   ├── (build) libdd-crashtracker v2.0.1 (*)
      │   ├── libdd-shared-runtime v4.0.0 (*)
      │   └── libdd-telemetry v8.0.0 (*)
      ├── libdd-crashtracker v2.0.1 (*)
      ├── (dev) libdd-ddsketch v1.1.1
      │   └── libdd-telemetry v8.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-common v6.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-data-pipeline-core - 3 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:63:1
   │
63 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v6.0.0
                     │   ├── libdd-capabilities-impl v5.0.0
                     │   │   └── libdd-trace-utils v12.0.0
                     │   │       ├── libdd-data-pipeline-core v1.0.0
                     │   │       ├── libdd-trace-obfuscation v8.0.0
                     │   │       │   └── libdd-data-pipeline-core v1.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v12.0.0 (*)
                     │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   ├── libdd-trace-obfuscation v8.0.0 (*)
                     │   └── libdd-trace-utils v12.0.0 (*)
                     ├── (dev) libdd-trace-normalization v4.0.0
                     │   └── libdd-trace-utils v12.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v8.0.0 (*)
                     └── (dev) libdd-trace-utils v12.0.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:100:1
    │
100 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0258
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
    ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
      If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
      
      Low severity.
      
      Patched in v0.4.16.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
    ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
    ├ h2 v0.4.6
      └── hyper v1.6.0
          ├── httpmock v0.8.0-alpha.1
          │   └── libdd-trace-utils v12.0.0
          │       ├── libdd-data-pipeline-core v1.0.0
          │       ├── libdd-trace-obfuscation v8.0.0
          │       │   └── libdd-data-pipeline-core v1.0.0 (*)
          │       └── (dev) libdd-trace-utils v12.0.0 (*)
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v6.0.0
          │       ├── libdd-capabilities-impl v5.0.0
          │       │   └── libdd-trace-utils v12.0.0 (*)
          │       ├── libdd-data-pipeline-core v1.0.0 (*)
          │       ├── libdd-trace-obfuscation v8.0.0 (*)
          │       └── libdd-trace-utils v12.0.0 (*)
          ├── hyper-util v0.1.17
          │   ├── httpmock v0.8.0-alpha.1 (*)
          │   ├── hyper-rustls v0.27.7 (*)
          │   └── libdd-common v6.0.0 (*)
          ├── libdd-common v6.0.0 (*)
          └── libdd-trace-utils v12.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:191:1
    │
191 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── (dev) libdd-common v6.0.0
      │   ├── libdd-capabilities-impl v5.0.0
      │   │   └── libdd-trace-utils v12.0.0
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       ├── libdd-trace-obfuscation v8.0.0
      │   │       │   └── libdd-data-pipeline-core v1.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v12.0.0 (*)
      │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   ├── libdd-trace-obfuscation v8.0.0 (*)
      │   └── libdd-trace-utils v12.0.0 (*)
      ├── (dev) libdd-trace-normalization v4.0.0
      │   └── libdd-trace-utils v12.0.0 (*)
      ├── libdd-trace-utils v12.0.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v6.0.0 (*)
          └── (dev) libdd-tinybytes v1.1.3
              ├── (dev) libdd-data-pipeline-core v1.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.3 (*)
              ├── (dev) libdd-trace-obfuscation v8.0.0 (*)
              └── libdd-trace-utils v12.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-data-pipeline-ffi - 4 error(s)

Show output
error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:79:1
   │
79 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v6.0.0
                     │   ├── libdd-capabilities-impl v5.0.0
                     │   │   ├── libdd-data-pipeline v10.0.0
                     │   │   │   └── libdd-data-pipeline-ffi v43.0.0
                     │   │   ├── libdd-data-pipeline-ffi v43.0.0 (*)
                     │   │   ├── libdd-shared-runtime v4.0.0
                     │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   │   │   ├── libdd-data-pipeline-ffi v43.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v6.0.0
                     │   │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v9.0.0
                     │   │   │   │       └── libdd-data-pipeline v10.0.0 (*)
                     │   │   │   ├── libdd-telemetry v8.0.0
                     │   │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v9.0.0 (*)
                     │   │   │   └── libdd-trace-stats v9.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v8.0.0 (*)
                     │   │   ├── libdd-trace-stats v9.0.0 (*)
                     │   │   └── libdd-trace-utils v12.0.0
                     │   │       ├── libdd-data-pipeline v10.0.0 (*)
                     │   │       ├── libdd-data-pipeline-core v1.0.0
                     │   │       │   └── libdd-data-pipeline v10.0.0 (*)
                     │   │       ├── (dev) libdd-data-pipeline-ffi v43.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v8.0.0
                     │   │       │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   │       │   ├── libdd-data-pipeline-ffi v43.0.0 (*)
                     │   │       │   └── libdd-trace-stats v9.0.0 (*)
                     │   │       ├── libdd-trace-stats v9.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v12.0.0 (*)
                     │   ├── libdd-common-ffi v43.0.0
                     │   │   └── libdd-data-pipeline-ffi v43.0.0 (*)
                     │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   ├── libdd-data-pipeline-core v1.0.0 (*)
                     │   ├── libdd-dogstatsd-client v6.0.0 (*)
                     │   ├── libdd-shared-runtime v4.0.0 (*)
                     │   ├── libdd-telemetry v8.0.0 (*)
                     │   ├── libdd-trace-obfuscation v8.0.0 (*)
                     │   ├── libdd-trace-stats v9.0.0 (*)
                     │   └── libdd-trace-utils v12.0.0 (*)
                     ├── (dev) libdd-data-pipeline v10.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   ├── libdd-telemetry v8.0.0 (*)
                     │   └── libdd-trace-stats v9.0.0 (*)
                     ├── (dev) libdd-trace-normalization v4.0.0
                     │   ├── libdd-data-pipeline v10.0.0 (*)
                     │   └── libdd-trace-utils v12.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v8.0.0 (*)
                     ├── (dev) libdd-trace-stats v9.0.0 (*)
                     └── (dev) libdd-trace-utils v12.0.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:122:1
    │
122 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0258
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
    ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
      If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
      
      Low severity.
      
      Patched in v0.4.16.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
    ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
    ├ h2 v0.4.6
      ├── hyper v1.6.0
      │   ├── httpmock v0.8.0-alpha.1
      │   │   ├── (dev) libdd-data-pipeline v10.0.0
      │   │   │   └── libdd-data-pipeline-ffi v43.0.0
      │   │   ├── (dev) libdd-data-pipeline-ffi v43.0.0 (*)
      │   │   ├── (dev) libdd-telemetry v8.0.0
      │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │   │   └── libdd-trace-stats v9.0.0
      │   │   │       └── libdd-data-pipeline v10.0.0 (*)
      │   │   ├── (dev) libdd-trace-stats v9.0.0 (*)
      │   │   └── libdd-trace-utils v12.0.0
      │   │       ├── libdd-data-pipeline v10.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0
      │   │       │   └── libdd-data-pipeline v10.0.0 (*)
      │   │       ├── (dev) libdd-data-pipeline-ffi v43.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v8.0.0
      │   │       │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-ffi v43.0.0 (*)
      │   │       │   └── libdd-trace-stats v9.0.0 (*)
      │   │       ├── libdd-trace-stats v9.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v12.0.0 (*)
      │   ├── hyper-rustls v0.27.7
      │   │   └── libdd-common v6.0.0
      │   │       ├── libdd-capabilities-impl v5.0.0
      │   │       │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-ffi v43.0.0 (*)
      │   │       │   ├── libdd-shared-runtime v4.0.0
      │   │       │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │       │   │   ├── libdd-data-pipeline-ffi v43.0.0 (*)
      │   │       │   │   ├── libdd-dogstatsd-client v6.0.0
      │   │       │   │   │   ├── libdd-data-pipeline v10.0.0 (*)
      │   │       │   │   │   └── libdd-trace-stats v9.0.0 (*)
      │   │       │   │   ├── libdd-telemetry v8.0.0 (*)
      │   │       │   │   └── libdd-trace-stats v9.0.0 (*)
      │   │       │   ├── (dev) libdd-telemetry v8.0.0 (*)
      │   │       │   ├── libdd-trace-stats v9.0.0 (*)
      │   │       │   └── libdd-trace-utils v12.0.0 (*)
      │   │       ├── libdd-common-ffi v43.0.0
      │   │       │   └── libdd-data-pipeline-ffi v43.0.0 (*)
      │   │       ├── libdd-data-pipeline v10.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v1.0.0 (*)
      │   │       ├── libdd-dogstatsd-client v6.0.0 (*)
      │   │       ├── libdd-shared-runtime v4.0.0 (*)
      │   │       ├── libdd-telemetry v8.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v8.0.0 (*)
      │   │       ├── libdd-trace-stats v9.0.0 (*)
      │   │       └── libdd-trace-utils v12.0.0 (*)
      │   ├── hyper-util v0.1.17
      │   │   ├── httpmock v0.8.0-alpha.1 (*)
      │   │   ├── hyper-rustls v0.27.7 (*)
      │   │   ├── libdd-common v6.0.0 (*)
      │   │   └── libdd-data-pipeline v10.0.0 (*)
      │   ├── libdd-common v6.0.0 (*)
      │   ├── libdd-common-ffi v43.0.0 (*)
      │   ├── libdd-data-pipeline v10.0.0 (*)
      │   └── libdd-trace-utils v12.0.0 (*)
      └── (dev) libdd-data-pipeline v10.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:231:1
    │
231 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to pr...*[Comment body truncated]*

@github-actions

github-actions Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 17347 documentation warning(s) found

📦 datadog-sidecar - 2927 warning(s)

📦 libdd-agent-client - 124 warning(s)

📦 libdd-capabilities-impl - 209 warning(s)

📦 libdd-capabilities - 35 warning(s)

📦 libdd-common - 169 warning(s)

📦 libdd-crashtracker - 1112 warning(s)

📦 libdd-data-pipeline-core - 805 warning(s)

📦 libdd-data-pipeline-ffi - 1405 warning(s)

📦 libdd-data-pipeline - 1294 warning(s)

📦 libdd-dogstatsd-client - 169 warning(s)

📦 libdd-ffe - 387 warning(s)

📦 libdd-http-client - ✅ No warnings

📦 libdd-ipc - 1019 warning(s)

📦 libdd-live-debugger - 1658 warning(s)

📦 libdd-profiling - 649 warning(s)

📦 libdd-remote-config - 682 warning(s)

📦 libdd-sampling - 136 warning(s)

📦 libdd-shared-runtime-ffi - 220 warning(s)

📦 libdd-shared-runtime - 213 warning(s)

📦 libdd-telemetry - 570 warning(s)

📦 libdd-tinybytes - 7 warning(s)

📦 libdd-trace-obfuscation - 853 warning(s)

📦 libdd-trace-stats - 914 warning(s)

📦 libdd-trace-utils - 765 warning(s)

📦 libdd-tracer-flare - 1025 warning(s)


Updated: 2026-09-04 15:53:09 UTC | Commit: f874d53 | missing-docs job results

@datadog-datadog-us1-prod datadog-datadog-us1-prod Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Datadog Autotest: PASS

More details

The release versions, dependency requirements, lock data, and change logs are consistent with the proposed release set.

Was this helpful? React 👍 or 👎

Open Bits AI session

🤖 Datadog Autotest · Commit ba2b103 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest

@datadog-datadog-us1-prod

datadog-datadog-us1-prod Bot commented Sep 4, 2026

Copy link
Copy Markdown

Tests

All CI checks and tests passed.

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 100.00%
Overall Coverage: 77.11% (+0.04%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: ba2b103 | Docs | View more details | Give us feedback!

@dd-octo-sts

dd-octo-sts Bot commented Sep 4, 2026

Copy link
Copy Markdown
Contributor Author

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 91.32 MB 91.31 MB --.01% (-9.50 KB) 💪
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.45 MB 8.45 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.38 MB 11.38 MB 0% (0 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 102.61 MB 102.61 MB +0% (+4.54 KB) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 27.32 MB 27.32 MB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 96.08 KB 96.08 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 185.41 MB 185.41 MB +0% (+8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 803.94 MB 803.81 MB --.01% (-129.89 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 9.00 MB 9.00 MB +.02% (+2.50 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 96.08 KB 96.08 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 26.20 MB 26.20 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 52.21 MB 52.21 MB +.01% (+8.58 KB) 🔍
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 23.82 MB 23.84 MB +.07% (+18.00 KB) 🔍
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 97.58 KB 97.58 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 190.45 MB 190.50 MB +.02% (+48.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 786.99 MB 787.81 MB +.10% (+845.46 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.96 MB 6.96 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 97.58 KB 97.58 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 28.19 MB 28.18 MB --.02% (-8.00 KB) 💪
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 49.70 MB 49.70 MB +0% (+742 B) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 81.48 MB 81.48 MB -0% (-3.02 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 9.41 MB 9.41 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 97.21 MB 97.21 MB +0% (+1.32 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.46 MB 11.46 MB -0% (-32 B) 👌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants