How severe is GHSA-gpwf-4h98-v82q?

GHSA-gpwf-4h98-v82q has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-gpwf-4h98-v82q?

GHSA-gpwf-4h98-v82q affects the following packages: datadog-opentelemetry (crates.io). Ecosystems affected: crates.io.

How do I fix GHSA-gpwf-4h98-v82q?

Update datadog-opentelemetry to 0.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gpwf-4h98-v82q is resolved across your whole dependency graph.

How do I detect GHSA-gpwf-4h98-v82q in my crates.io dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for datadog-opentelemetry, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-gpwf-4h98-v82q if there is no patch (or I can't update yet)?

Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Is GHSA-gpwf-4h98-v82q actively exploited in the wild?

No public exploit code has been indexed for GHSA-gpwf-4h98-v82q yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-gpwf-4h98-v82q?

GHSA-gpwf-4h98-v82q has an EPSS (Exploit Prediction Scoring System) score of 0.8%, placing it in the 55th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-gpwf-4h98-v82q?

GHSA-gpwf-4h98-v82q is classified as CWE-770 (CWE-770). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-gpwf-4h98-v82q published, and has it been updated?

GHSA-gpwf-4h98-v82q was published on August 28, 2026 and was last updated on August 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🦀

🦀 crates.io

Not in CISA KEV

HIGH severity

datadog-opentelemetry has unbounded W3C tracestate parsing that may lead to DoSGHSA-gpwf-4h98-v82q

HIGHFix: DataDog/dd-trace-rs#218

GHSA-gpwf-4h98-v82q is a high-severity (CVSS 7.5) CWE-770 vulnerability in datadog-opentelemetry. A fix is available for datadog-opentelemetry — see the affected versions and patch details below.

Also known asCVE-2026-54788

Published

Aug 28, 2026

Updated

Aug 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 12, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗

0.8%probability of exploitation in next 30 days

Lower Risk+0.23%

Lower risk than most CVEs55th percentile — riskier than 55% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-gpwf-4h98-v82q by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,987 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected

🦀datadog-opentelemetry

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

Impact

Datadog tracing libraries that implement W3C Trace Context (tracecontext) propagation parse the incoming tracestate header without enforcing a size cap on the Datadog vendor entry (dd=...). The dd= value contains semicolon-separated key:value pairs, and the parser allocates a hash-map entry for each pair. A remote, unauthenticated attacker can send a tracestate header whose dd= member is arbitrarily large (or contains an arbitrarily large number of pairs), forcing unbounded CPU and memory consumption per request and enabling a remote Denial of Service. tracecontext extraction is enabled by default in affected tracers, so any internet-facing service instrumented with an affected version is exposed unless tracecontext has been explicitly removed from the propagation style configuration.

Patches

This is resolved in version 0.3.3 and later of the dd-trace-rs library.

Workarounds

If you cannot upgrade immediately:

Disable tracecontext extraction by setting DD_TRACE_PROPAGATION_STYLE_EXTRACT to a value that does not include tracecontext (for example, datadog).
Cap the maximum HTTP request header size at an upstream proxy or web server.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🦀crates.io	`datadog-opentelemetry`	≥ 0.1.0&&< 0.3.3	0.3.3`cargo update -p datadog-opentelemetry --precise 0.3.3`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for datadog-opentelemetry, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update datadog-opentelemetry to 0.3.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gpwf-4h98-v82q is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### Impact Datadog tracing libraries that implement W3C Trace Context (`tracecontext`) propagation parse the incoming `tracestate` header without enforcing a size cap on the Datadog vendor entry (`dd=...`). The `dd=` value contains semicolon-separated `key:value` pairs, and the parser allocates a hash-map entry for each pair. A remote, unauthenticated attacker can send a `tracestate` header whose `dd=` member is arbitrarily large (or contains an arbitrarily large number of pairs), forcing unbounded CPU and memory consumption per request and enabling a remote Denial of Service. `tracecontext` e