fix: force @opentelemetry/core to 2.8.0 to resolve GHSA-8988-4f7v-96qf

[Copilot]

@opentelemetry/core ≤2.7.1 does not enforce W3C Baggage spec limits on the inbound extract() path, allowing oversized baggage headers to cause memory allocation proportional to header size. Fix is 2.8.0 which caps at 8,192 bytes / 180 entries.

Changes

• package.json: Added "@opentelemetry/core": "2.8.0" to the overrides block — necessary because the package enters the tree transitively through applicationinsights and several @opentelemetry/* sub-packages all pinned to 2.7.1.
• package-lock.json: Regenerated; only one copy of @opentelemetry/core (2.8.0) is installed on disk.

Reachability

The app does not call W3CBaggagePropagator.extract() directly. The propagator is registered by the applicationinsights SDK at startup but would only fire on requests carrying a baggage HTTP header — GitHub webhook deliveries do not include one. Node.js's default 16 KB --max-http-header-size cap also constrains any external vector. Not actively exploitable in this deployment; update addresses scanner compliance and defense-in-depth.

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>OpenTelemetry Core: Unbounded memory allocation in W3C Baggage propagation</alert_title>
<alert_description>## Overview

W3CBaggagePropagator.extract() in @opentelemetry/core does not enforce size limits when parsing inbound baggage HTTP headers. The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; these limits were only enforced on the outbound (inject()) path, not on the inbound (extract()) path. Parsing oversized baggage causes memory allocation proportional to the header size without any cap.

Impact

The practical availability impact for most Node.js deployments is limited. Node.js enforces a default --max-http-header-size of 16,384 bytes on the total combined size of all HTTP headers, constraining what an external attacker can deliver before the propagator is reached. Additionally, the header is already in memory (parsed by the HTTP layer) by the time it reaches the propagator - the additional allocation is the overhead of splitting into entry objects, not an unbounded read.

The risk is higher when transport-layer limits are absent - e.g., non-HTTP transports (messaging systems, custom TextMapGetter implementations) or deployments that have raised --max-http-header-size.

Remediation

Update @opentelemetry/core to version 2.8.0 or later. The fix enforces limits consistent with the W3C Baggage specification at the propagator level:

• Maximum total baggage size: 8,192 bytes
• Maximum number of entries: 180
• Maximum per-entry size: 4,096 bytes

Headers that exceed these limits are truncated at the point the limit is reached.

Workarounds

Ensure header size limits are configured at the server or gateway level. The default Node.js HTTP header limit (16 KB) mitigates external attack vectors independently of this fix. For non-HTTP transports receiving baggage from untrusted sources, validate input size before passing it to the propagator.

References

• W3C Baggage Specification - Limits
• opentelemetry-java: GHSA-rcgg-9c38-7xpx
• opentelemetry-go: GHSA-mh2q-q3fh-2475

Credit

Reported by tonghuaroot.</alert_description>

moderate
GHSA-8988-4f7v-96qf, CVE-2026-54285
@opentelemetry/core
npm
<vulnerable_versions>2.7.1</vulnerable_versions>
<patched_version>2.8.0</patched_version>
<manifest_path>package-lock.json</manifest_path>

https://github.com/open-telemetry/opentelemetry-js/security/advisories/GHSA-8988-4f7v-96qf https://github.com/advisories/GHSA-8988-4f7v-96qf

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identifier explaining it is a temporary mitigation. If neither a patch nor a workaround is available, explain in the PR description why the alert cannot be resolved automatically so a human reviewer can take over. Inspect the repository to determine which package manager is used (e.g. lock files, config files, build scripts) and use that tooling to perform the update — do not edit lock files directly. If the version constraint in the manifest ...

• Resolves github/copilot-survey-engine alert Update Node.js image to specific SHA256 digest #45