Skip to content

chore(release): proposal for libdd-capabilities-impl, libdd-common, libdd-data-pipeline, libdd-li... - #2619

Merged
iunanua merged 46 commits into
release/libdd-capabilities-impl-10-more/20261002-120212from
release-proposal/libdd-capabilities-impl-10-more/20261002-120212
Oct 2, 2026
Merged

chore(release): proposal for libdd-capabilities-impl, libdd-common, libdd-data-pipeline, libdd-li...#2619
iunanua merged 46 commits into
release/libdd-capabilities-impl-10-more/20261002-120212from
release-proposal/libdd-capabilities-impl-10-more/20261002-120212

Conversation

@dd-octo-sts

@dd-octo-sts dd-octo-sts Bot commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

Release proposal for libdd-capabilities-impl, libdd-common, libdd-data-pipeline, libdd-library-config, libdd-profiling-heap-allocator, libdd-remote-config, libdd-sampling, libdd-shared-runtime, libdd-telemetry, libdd-tinybytes, libdd-trace-utils and their 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 6.0.0 → 7.0.0 affects: libdd-crashtracker, libdd-live-debugger, libdd-tracer-flare
  • libdd-common 7.0.0 → 8.0.0 affects: libdd-crashtracker, libdd-ffe, libdd-http-client, libdd-ipc, libdd-live-debugger, libdd-profiling, libdd-tracer-flare
  • libdd-data-pipeline 11.0.0 → 12.0.0 affects: libdd-live-debugger
  • libdd-remote-config 6.0.0 → 7.0.0 affects: libdd-ffe, libdd-live-debugger, libdd-tracer-flare
  • libdd-telemetry 9.0.0 → 10.0.0 affects: libdd-crashtracker
  • libdd-trace-stats 10.0.0 → 11.0.0 affects: libdd-ipc
  • libdd-trace-utils 13.0.0 → 14.0.0 affects: libdd-tracer-flare

libdd-capabilities

Next version: 4.0.1
Semver bump: patch
Tag: libdd-capabilities-v4.0.1

Commits

libdd-common

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

Commits

libdd-ddsketch

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

Commits

libdd-profiling-heap-sampler

Next version: 1.1.1
Semver bump: patch
Tag: libdd-profiling-heap-sampler-v1.1.1

Commits

libdd-tinybytes

Next version: 1.1.5
Semver bump: patch
Tag: libdd-tinybytes-v1.1.5

Commits

libdd-trace-protobuf

Next version: 5.1.0
Semver bump: minor
Tag: libdd-trace-protobuf-v5.1.0

Commits

libdd-capabilities-impl

Next version: 7.0.0
Semver bump: major
Tag: libdd-capabilities-impl-v7.0.0

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0

Commits

libdd-profiling-heap-allocator

Next version: 1.2.0
Semver bump: minor
Tag: libdd-profiling-heap-allocator-v1.2.0

Commits

libdd-library-config

Next version: 4.2.0
Semver bump: minor
Tag: libdd-library-config-v4.2.0

Commits

libdd-trace-normalization

Next version: 4.2.0
Semver bump: minor
Tag: libdd-trace-normalization-v4.2.0

Commits

libdd-remote-config

Next version: 7.0.0
Semver bump: major
Tag: libdd-remote-config-v7.0.0

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0

Commits

libdd-shared-runtime

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

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0

Commits

libdd-trace-utils

Next version: 14.0.0
Semver bump: major
Tag: libdd-trace-utils-v14.0.0

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0

Commits

libdd-dogstatsd-client

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

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0

Commits

libdd-telemetry

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

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0

Commits

libdd-sampling

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

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0
  • libdd-trace-utils: ^13.0.0 → ^14.0.0

Commits

libdd-trace-obfuscation

Next version: 10.0.0
Semver bump: major
Tag: libdd-trace-obfuscation-v10.0.0

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0
  • libdd-trace-utils: ^13.0.0 → ^14.0.0

Commits

libdd-trace-stats

Next version: 11.0.0
Semver bump: major
Tag: libdd-trace-stats-v11.0.0

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0
  • libdd-telemetry: ^9.0.0 → ^10.0.0
  • libdd-trace-obfuscation: ^9.0.0 → ^10.0.0
  • libdd-trace-utils: ^13.0.0 → ^14.0.0

Commits

libdd-data-pipeline-core

Next version: 3.0.0
Semver bump: major
Tag: libdd-data-pipeline-core-v3.0.0

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0
  • libdd-trace-obfuscation: ^9.0.0 → ^10.0.0
  • libdd-trace-stats: ^10.0.0 → ^11.0.0
  • libdd-trace-utils: ^13.0.0 → ^14.0.0

Commits

libdd-data-pipeline

Next version: 12.0.0
Semver bump: major
Tag: libdd-data-pipeline-v12.0.0

⚠️ major bump forced due to:

  • libdd-common: ^7.0.0 → ^8.0.0
  • libdd-telemetry: ^9.0.0 → ^10.0.0
  • libdd-trace-obfuscation: ^9.0.0 → ^10.0.0
  • libdd-trace-stats: ^10.0.0 → ^11.0.0
  • libdd-trace-utils: ^13.0.0 → ^14.0.0

Commits

github-actions Bot and others added 30 commits October 2, 2026 12:37
@github-actions @iunanua
chore: Release
123c1ba 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
8f62c47 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
76b88d7 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
3bd5a88 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
c33f70d 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
32851d7 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
b3c69be 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
97bb520 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
a61a428 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
1f24d52 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
e9b8ef6 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
54813de 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
dcaa8d8 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
9805e31 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
7d4e34d 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
689cc91 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
014d1fd 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
7c5a1f6 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
39b4814 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore: Release
19a1abb 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update version for libdd-capabilities-impl with major…
c7e71dc 
… bumps

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update version for libdd-remote-config with major bumps
efd31c6 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update version for libdd-shared-runtime with major bumps
fcee3a5 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update version for libdd-dogstatsd-client with major …
9ea8769 
…bumps

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update version for libdd-sampling with major bumps
5d2a578 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update version for libdd-data-pipeline-core with majo…
d788208 
…r bumps

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update CHANGELOG.md for libdd-capabilities
2cd3db4 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update CHANGELOG.md for libdd-common
e36d265 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update CHANGELOG.md for libdd-ddsketch
61fa61e 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions @iunanua
chore(release): update CHANGELOG.md for libdd-profiling-heap-sampler
d251a87 
Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>
@github-actions

github-actions Bot commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

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

📦 datadog-sidecar - 3 error(s)

Show output 
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:35:1
   │
35 │ 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 v2.0.0
     │   └── datadog-sidecar v0.0.1 (*)
     └── libdd-ipc v2.0.0
         └── datadog-sidecar v0.0.1 (*)

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:230:1
    │
230 │ 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 v2.0.0
          └── datadog-sidecar v0.0.1

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:331:1
    │
331 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── datadog-sidecar v0.0.1
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── datadog-sidecar v0.0.1 (*)
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   └── libdd-crashtracker-ffi v44.0.0
      │       │   │       └── datadog-sidecar v0.0.1 (*)
      │       │   ├── libdd-data-pipeline v12.0.0
      │       │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   └── libdd-live-debugger v1.0.0
      │       │   │       └── datadog-sidecar v0.0.1 (*)
      │       │   ├── (dev) libdd-ffe v2.0.0
      │       │   │   └── datadog-sidecar v0.0.1 (*)
      │       │   ├── libdd-live-debugger v1.0.0 (*)
      │       │   ├── libdd-remote-config v7.0.0
      │       │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │       │   │   ├── libdd-ffe v2.0.0 (*)
      │       │   │   ├── libdd-live-debugger v1.0.0 (*)
      │       │   │   └── (dev) libdd-remote-config v7.0.0 (*)
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v8.0.0
      │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v11.0.0
      │       │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │       ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   │       └── libdd-ipc v2.0.0
      │       │   │   │           └── datadog-sidecar v0.0.1 (*)
      │       │   │   ├── libdd-telemetry v10.0.0
      │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │       │   │   │   ├── libdd-crashtracker v3.0.0 (*)
      │       │   │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v11.0.0 (*)
      │       │   │   └── libdd-trace-stats v11.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v10.0.0 (*)
      │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │       │       ├── libdd-data-pipeline v12.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v3.0.0
      │       │       │   └── libdd-data-pipeline v12.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v3.0.0 (*)
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-common-ffi v44.0.0
      │       │   ├── datadog-sidecar v0.0.1 (*)
      │       │   └── libdd-crashtracker-ffi v44.0.0 (*)
      │       ├── (build) libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-crashtracker-ffi v44.0.0 (*)
      │       ├── libdd-data-pipeline v12.0.0 (*)
      │       ├── libdd-data-pipeline-core v3.0.0 (*)
      │       ├── libdd-dogstatsd-client v8.0.0 (*)
      │       ├── libdd-ffe v2.0.0 (*)
      │       ├── libdd-ipc v2.0.0 (*)
      │       ├── libdd-live-debugger v1.0.0 (*)
      │       ├── libdd-remote-config v7.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       ├── libdd-telemetry v10.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       ├── libdd-trace-stats v11.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

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

Show output 
error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:85:1
   │
85 │ 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 v2.0.0
                 └── libdd-agent-client v44.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:85:1
   │
85 │ 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 v2.0.0
                 └── libdd-agent-client v44.0.0

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:173:1
    │
173 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── reqwest v0.13.2
      │       └── libdd-http-client v2.0.0
      │           └── libdd-agent-client v44.0.0
      ├── (dev) libdd-agent-client v44.0.0 (*)
      ├── (dev) libdd-http-client v2.0.0 (*)
      ├── reqwest v0.13.2 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── reqwest v0.13.2 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── reqwest v0.13.2 (*)

advisories FAILED, bans ok, sources ok

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

Show output 
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:85:1
   │
85 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0285
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
   ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
     when they followed a key-changing message in the same record. For example,
     a plaintext `EncryptedExtensions` message packed into the same record as the
     `ServerHello` was accepted.
     
     RFC 8446 section 5.1 requires that handshake messages do not span key changes,
     and that implementations terminate the connection with an "unexpected_message"
     alert if they do.
     
     The handshake transcript is still authenticated, so a network-position attacker
     cannot use this to alter or complete a handshake; the practical effect is that
     a peer could send handshake messages that should be encrypted in plaintext
     without rustls rejecting the connection.
     
     This is functionally the same bug as Go's
     [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
   ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
   ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
   ├ rustls v0.23.37
     ├── hyper-rustls v0.27.7
     │   └── libdd-common v8.0.0
     │       └── libdd-capabilities-impl v7.0.0
     ├── libdd-common v8.0.0 (*)
     ├── rustls-platform-verifier v0.6.2
     │   └── libdd-common v8.0.0 (*)
     └── tokio-rustls v0.26.0
         └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-capabilities - ✅ No issues

📦 libdd-common - 3 error(s)

Show output 
error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:67:1
   │
67 │ 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 v8.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:67:1
   │
67 │ 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 v8.0.0

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:150:1
    │
150 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   ├── libdd-common v8.0.0
      │   └── reqwest v0.13.2
      │       └── libdd-common v8.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── reqwest v0.13.2 (*)
      ├── rustls-platform-verifier v0.6.2
      │   ├── libdd-common v8.0.0 (*)
      │   └── reqwest v0.13.2 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── reqwest v0.13.2 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-crashtracker - 1 error(s)

Show output 
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:223:1
    │
223 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── libdd-crashtracker v3.0.0
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   └── libdd-telemetry v10.0.0
      │       │   │       └── libdd-crashtracker v3.0.0 (*)
      │       │   └── (dev) libdd-telemetry v10.0.0 (*)
      │       ├── (build) libdd-crashtracker v3.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       └── libdd-telemetry v10.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

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

Show output 
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:216:1
    │
216 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-data-pipeline-core v3.0.0
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   └── libdd-data-pipeline-core v3.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-data-pipeline-core v3.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

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

Show output 
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:250:1
    │
250 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── libdd-data-pipeline v12.0.0
      │       │   │   └── libdd-data-pipeline-ffi v44.0.0
      │       │   ├── libdd-data-pipeline-ffi v44.0.0 (*)
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   ├── libdd-data-pipeline-ffi v44.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v8.0.0
      │       │   │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v11.0.0
      │       │   │   │       └── libdd-data-pipeline v12.0.0 (*)
      │       │   │   ├── libdd-telemetry v10.0.0
      │       │   │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v11.0.0 (*)
      │       │   │   └── libdd-trace-stats v11.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v10.0.0 (*)
      │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-data-pipeline v12.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v3.0.0
      │       │       │   └── libdd-data-pipeline v12.0.0 (*)
      │       │       ├── (dev) libdd-data-pipeline-ffi v44.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v3.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-ffi v44.0.0 (*)
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-common-ffi v44.0.0
      │       │   └── libdd-data-pipeline-ffi v44.0.0 (*)
      │       ├── libdd-data-pipeline v12.0.0 (*)
      │       ├── libdd-data-pipeline-core v3.0.0 (*)
      │       ├── libdd-data-pipeline-ffi v44.0.0 (*)
      │       ├── libdd-dogstatsd-client v8.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       ├── libdd-telemetry v10.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       ├── libdd-trace-stats v11.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-data-pipeline - 1 error(s)

Show output 
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:242:1
    │
242 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── libdd-data-pipeline v12.0.0
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v8.0.0
      │       │   │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v11.0.0
      │       │   │   │       └── libdd-data-pipeline v12.0.0 (*)
      │       │   │   ├── libdd-telemetry v10.0.0
      │       │   │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v11.0.0 (*)
      │       │   │   └── libdd-trace-stats v11.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v10.0.0 (*)
      │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-data-pipeline v12.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v3.0.0
      │       │       │   └── libdd-data-pipeline v12.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v3.0.0 (*)
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-data-pipeline v12.0.0 (*)
      │       ├── libdd-data-pipeline-core v3.0.0 (*)
      │       ├── libdd-dogstatsd-client v8.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       ├── libdd-telemetry v10.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       ├── libdd-trace-stats v11.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-ddsketch - ✅ No issues

📦 libdd-dogstatsd-client - 1 error(s)

Show output 
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:93:1
   │
93 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0285
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
   ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
     when they followed a key-changing message in the same record. For example,
     a plaintext `EncryptedExtensions` message packed into the same record as the
     `ServerHello` was accepted.
     
     RFC 8446 section 5.1 requires that handshake messages do not span key changes,
     and that implementations terminate the connection with an "unexpected_message"
     alert if they do.
     
     The handshake transcript is still authenticated, so a network-position attacker
     cannot use this to alter or complete a handshake; the practical effect is that
     a peer could send handshake messages that should be encrypted in plaintext
     without rustls rejecting the connection.
     
     This is functionally the same bug as Go's
     [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
   ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
   ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
   ├ rustls v0.23.37
     ├── hyper-rustls v0.27.7
     │   └── libdd-common v8.0.0
     │       ├── libdd-capabilities-impl v7.0.0
     │       │   └── libdd-shared-runtime v6.0.0
     │       │       └── libdd-dogstatsd-client v8.0.0
     │       ├── libdd-dogstatsd-client v8.0.0 (*)
     │       └── libdd-shared-runtime v6.0.0 (*)
     ├── libdd-common v8.0.0 (*)
     ├── rustls-platform-verifier v0.6.2
     │   └── libdd-common v8.0.0 (*)
     └── tokio-rustls v0.26.0
         └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-ffe - 3 error(s)

Show output 
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:22:1
   │
22 │ 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
     └── (dev) libdd-ffe v2.0.0

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:128:1
    │
128 │ 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 v2.0.0

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:170:1
    │
170 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── (dev) libdd-ffe v2.0.0
      │       │   └── libdd-remote-config v7.0.0
      │       │       ├── libdd-ffe v2.0.0 (*)
      │       │       └── (dev) libdd-remote-config v7.0.0 (*)
      │       ├── libdd-ffe v2.0.0 (*)
      │       └── libdd-remote-config v7.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-http-client - 3 error(s)

Show output 
error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:71:1
   │
71 │ 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 v2.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:71:1
   │
71 │ 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 v2.0.0

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:144:1
    │
144 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── reqwest v0.13.2
      │       └── libdd-http-client v2.0.0
      ├── (dev) libdd-http-client v2.0.0 (*)
      ├── reqwest v0.13.2 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── reqwest v0.13.2 (*)
      └── tokio-rustls v0.26.0
          ├── hyper-rustls v0.27.7 (*)
          └── reqwest v0.13.2 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-ipc - 2 error(s)

Show output 
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ 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
     └── libdd-ipc v2.0.0

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:229:1
    │
229 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   └── libdd-trace-stats v11.0.0
      │       │   │       └── libdd-ipc v2.0.0
      │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-ipc v2.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       ├── libdd-trace-stats v11.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-library-config - ✅ No issues

📦 libdd-live-debugger - 1 error(s)

Show output 
error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:246:1
    │
246 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they followed a key-changing message in the same record. For example,
      a plaintext `EncryptedExtensions` message packed into the same record as the
      `ServerHello` was accepted.
      
      RFC 8446 section 5.1 requires that handshake messages do not span key changes,
      and that implementations terminate the connection with an "unexpected_message"
      alert if they do.
      
      The handshake transcript is still authenticated, so a network-position attacker
      cannot use this to alter or complete a handshake; the practical effect is that
      a peer could send handshake messages that should be encrypted in plaintext
      without rustls rejecting the connection.
      
      This is functionally the same bug as Go's
      [GO-2026-4340](https://pkg.go.dev/vuln/GO-2026-4340) (CVE-2025-61730).
    ├ Announcement: https://github.com/rustls/rustls/security/advisories/GHSA-2mjx-qc3c-rqvc
    ├ Solution: Upgrade to >=0.23.45 (try `cargo update -p rustls`)
    ├ rustls v0.23.37
      ├── hyper-rustls v0.27.7
      │   └── libdd-common v8.0.0
      │       ├── libdd-capabilities-impl v7.0.0
      │       │   ├── libdd-data-pipeline v12.0.0
      │       │   │   └── libdd-live-debugger v1.0.0
      │       │   ├── libdd-live-debugger v1.0.0 (*)
      │       │   ├── libdd-remote-config v7.0.0
      │       │   │   ├── libdd-live-debugger v1.0.0 (*)
      │       │   │   └── (dev) libdd-remote-config v7.0.0 (*)
      │       │   ├── libdd-shared-runtime v6.0.0
      │       │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   ├── libdd-dogstatsd-client v8.0.0
      │       │   │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v11.0.0
      │       │   │   │       └── libdd-data-pipeline v12.0.0 (*)
      │       │   │   ├── libdd-telemetry v10.0.0
      │       │   │   │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │   │   │   └── libdd-trace-stats v11.0.0 (*)
      │       │   │   └── libdd-trace-stats v11.0.0 (*)
      │       │   ├── (dev) libdd-telemetry v10.0.0 (*)
      │       │   ├── libdd-trace-stats v11.0.0 (*)
      │       │   └── libdd-trace-utils v14.0.0
      │       │       ├── libdd-data-pipeline v12.0.0 (*)
      │       │       ├── libdd-data-pipeline-core v3.0.0
      │       │       │   └── libdd-data-pipeline v12.0.0 (*)
      │       │       ├── libdd-trace-obfuscation v10.0.0
      │       │       │   ├── libdd-data-pipeline v12.0.0 (*)
      │       │       │   ├── libdd-data-pipeline-core v3.0.0 (*)
      │       │       │   └── libdd-trace-stats v11.0.0 (*)
      │       │       ├── libdd-trace-stats v11.0.0 (*)
      │       │       └── (dev) libdd-trace-utils v14.0.0 (*)
      │       ├── libdd-data-pipeline v12.0.0 (*)
      │       ├── libdd-data-pipeline-core v3.0.0 (*)
      │       ├── libdd-dogstatsd-client v8.0.0 (*)
      │       ├── libdd-live-debugger v1.0.0 (*)
      │       ├── libdd-remote-config v7.0.0 (*)
      │       ├── libdd-shared-runtime v6.0.0 (*)
      │       ├── libdd-telemetry v10.0.0 (*)
      │       ├── libdd-trace-obfuscation v10.0.0 (*)
      │       ├── libdd-trace-stats v11.0.0 (*)
      │       └── libdd-trace-utils v14.0.0 (*)
      ├── libdd-common v8.0.0 (*)
      ├── rustls-platform-verifier v0.6.2
      │   └── libdd-common v8.0.0 (*)
      └── tokio-rustls v0.26.0
          └── hyper-rustls v0.27.7 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-profiling-heap-allocator - ✅ No issues

📦 libdd-profiling-heap-gotter - ✅ No issues

📦 libdd-profiling-heap-sampler - ✅ No issues

📦 libdd-profiling - 5 error(s)

Show output 
error[unsound]: `Bitmap::try_from(&[u8])` can create invalid values
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:16:1
   │
16 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2025-0167
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0167
   ├ The `TryFrom<&[u8]>` implementation for `Bitmap<SIZE>` copies the input bytes
     into an uninitialized backing store and calls `assume_init()` without
     validating that the bytes form a valid value of the backing store type. For
     `SIZE = 1` the backing store is a `bool`, so any input byte other than `0x00`
     or `0x01` produces an invalid value, which is immediate undefined behavior.
     
     The `AsMut<[u8]>` implementation has the same problem, as it allows safe code
     to write invalid bit patterns into the backing store through the returned slice.
     
     No fixed version is available, as the crate is unmaintained; its GitHub
     repository was archived by the owner on 2026-05-03.
   ├ Announcement: https://github.com/bodil/bitmaps/issues/35
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[unmaintained]: bitmaps is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:16:1
   │
16 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2026-0247
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0247
   ├ The bitmaps crate is unmaintained; all versions are affected. The GitHub
     repository was archived by the owner on 2026-05-03.
     
     Recommended alternatives:
     
     * [fixedbitset](https://crates.io/crates/fixedbitset)
     * [bitvec](https://crates.io/crates/bitvec)
   ├ Announcement: https://github.com/bodil/bitmaps
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:81:1
   │
81 │ 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 v8.0.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:81:1
   │
81 │ 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 v8.0.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

error[vulnerability]: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:178:1
    │
178 │ rustls 0.23.37 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0285
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0285
    ├ Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
      when they f...*[Comment body truncated]*

@github-actions

github-actions Bot commented Oct 2, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 18351 documentation warning(s) found

📦 datadog-sidecar - 2938 warning(s)

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

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

📦 libdd-capabilities - 36 warning(s)

📦 libdd-common - 168 warning(s)

📦 libdd-crashtracker - 1120 warning(s)

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

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

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

📦 libdd-ddsketch - 8 warning(s)

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

📦 libdd-ffe - 386 warning(s)

📦 libdd-http-client - ✅ No warnings

📦 libdd-ipc - 1021 warning(s)

📦 libdd-library-config - 269 warning(s)

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

📦 libdd-profiling-heap-allocator - 49 warning(s)

📦 libdd-profiling-heap-gotter - 56 warning(s)

📦 libdd-profiling-heap-sampler - 49 warning(s)

📦 libdd-profiling - 648 warning(s)

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

📦 libdd-sampling - 135 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-normalization - 248 warning(s)

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

📦 libdd-trace-protobuf - 231 warning(s)

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

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

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

Updated: 2026-10-02 12:45:03 UTC | Commit: 10d7a86 | missing-docs job results

@iunanua
iunanua marked this pull request as ready for review October 2, 2026 12:49
@iunanua
iunanua requested review from a team as code owners October 2, 2026 12:49
@iunanua
iunanua requested review from btthomas, danyal002 and vpellan and removed request for a team October 2, 2026 12:49
@datadog-prod-us1-4

datadog-prod-us1-4 Bot commented Oct 2, 2026 •
edited by datadog-official Bot
Loading

Copy link
Copy Markdown

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 80.12% (-0.06%)

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

@dd-octo-sts

dd-octo-sts Bot commented Oct 2, 2026 •
edited
Loading

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.so 9.08 MB 9.08 MB 0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 96.60 MB 96.62 MB +.01% (+12.15 KB) 🔍
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.27 MB 12.27 MB -0% (-112 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 107.95 MB 107.93 MB --.01% (-16.16 KB) 💪
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 29.09 MB 29.08 MB --.04% (-13.50 KB) 💪
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 97.94 KB 97.94 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 191.84 MB 191.76 MB --.04% (-80.00 KB) 💪
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 818.80 MB 819.14 MB +.04% (+348.14 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 9.76 MB 9.76 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 97.94 KB 97.94 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 27.60 MB 27.61 MB +.02% (+8.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 55.79 MB 55.80 MB +0% (+5.07 KB) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 25.51 MB 25.51 MB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 99.47 KB 99.47 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 197.52 MB 197.46 MB --.03% (-64.00 KB) 💪
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 803.12 MB 803.61 MB +.06% (+504.88 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 7.58 MB 7.58 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 99.47 KB 99.47 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 29.72 MB 29.73 MB +.02% (+8.00 KB) 🔍
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 52.72 MB 52.73 MB +.02% (+11.85 KB) 🔍
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 86.50 MB 86.49 MB --.01% (-9.44 KB) 💪
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 10.11 MB 10.11 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 102.38 MB 102.38 MB -0% (-5.02 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.35 MB 12.35 MB -0% (-392 B) 👌

@iunanua
iunanua merged commit 05056f8 into release/libdd-capabilities-impl-10-more/20261002-120212 Oct 2, 2026
115 of 120 checks passed
@iunanua
iunanua deleted the release-proposal/libdd-capabilities-impl-10-more/20261002-120212 branch October 2, 2026 13:16
@dd-octo-sts dd-octo-sts Bot mentioned this pull request Oct 2, 2026
Merged
gh-worker-dd-mergequeue-cf854d Bot pushed a commit that referenced this pull request Oct 2, 2026
@dd-octo-sts @iunanua
chore(release): merge release branch to main (#2619) (#2621)
7f3b16f 
proposal for libdd-capabilities-impl, libdd-common, libdd-data-pipeline, libdd-li... (#2619)

Co-authored-by: igor.unanua <igor.unanua@datadoghq.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@btthomas btthomas Awaiting requested review from btthomas btthomas was automatically assigned from DataDog/feature-flagging-and-experimentation-sdk
@danyal002 danyal002 Awaiting requested review from danyal002 danyal002 was automatically assigned from DataDog/feature-flagging-and-experimentation-sdk
@vpellan vpellan Awaiting requested review from vpellan vpellan was automatically assigned from DataDog/apm-sdk-capabilities-rust

Assignees

No one assigned

Labels

common crashtracker data-pipeline mini-agent release-proposal This is a release proposal PR sampling sidecar skip-changelog-check skip-metadata-check skip-pr-title-semver-check telemetry

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@iunanua