chore: upgrade @opentelemetry/core to ^2.8.0 to address CVE-2026-54285

[linear-code]

Fixes SOU-1359

Addresses CVE-2026-54285 (unbounded memory allocation in W3C Baggage propagation, @opentelemetry/core < 2.8.0).

Refreshing the lockfile (yarn up -R @opentelemetry/core) bumped the caret-ranged requesters to 2.8.0, but several deep transitive packages under @sentry/node and posthog-js pin @opentelemetry/core to exact versions (2.0.1, 2.2.0, 2.5.0, 2.5.1). Since no single top-level bump covers all of these, qualified resolutions overrides pin each to ^2.8.0. All instances now resolve to 2.8.0 (verified via yarn why @opentelemetry/core --recursive).

[github-actions]

License Audit

❌ Audit failed to produce results. Check the workflow logs for details.

[brendan-kellam]

@claude can you cross-validate that bumping the top level packages by either a patch or a minor would not solve this issue?

[claude]

Claude finished @brendan-kellam's task in 5m 2s —— View job

---

Cross-validation: can a top-level patch/minor bump avoid the resolutions overrides?

• Identify top-level packages that pull in @opentelemetry/core
• Trace the transitive chains to the pinned 2.0.1 / 2.2.0 / 2.5.0 / 2.5.1 versions
• Check whether a patch/minor bump of each top-level package lifts those pins to ≥ 2.8.0
• Report findings

Why the deep pins are sticky

Every blocked version comes from an OpenTelemetry package that pins @opentelemetry/core to an exact version internally (e.g. @opentelemetry/instrumentation-http@0.211.0 → "@opentelemetry/core": "npm:2.5.0", not ^2.5.0). So a given OTel package only stops pulling old core when it advances to the package version from the core-2.8.0 release wave (stable 2.8.0 ↔ experimental ~0.214.x). A top-level bump helps only if a reachable patch/minor re-bundles that wave.

Ownership of each pin (traced from origin/mainyarn.lock)

Pinned core	Pulled in by (exact requester)	Top-level owner & range	Patch/minor fixes it?
2.0.1	@opentelemetry/sdk-logs@0.203.0, instrumentation@0.203.0, api-logs@0.203.0	packages/web direct deps@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0	No — provably
2.2.0	@opentelemetry/exporter-logs-otlp-http@^0.208.0 + the 0.208.0/2.2.0 wave	posthog-js@^1.369.0; also @fastify/otel@0.16.0 (pinned by Sentry)	Unverifiable offline
2.5.0	@opentelemetry/instrumentation-http@0.211.0 (exact)	@sentry/node@^10.40.0 (+ nextjs/profiling-node)	Unverifiable offline
2.5.1	@opentelemetry/resources@2.5.1; sdk-trace-base@^2.5.1	root resolutions override"@opentelemetry/resources": "2.5.1" + Sentry's ^2.5.1 (caret already admits 2.8.0)	Self-imposed

Findings

1. core 2.0.1 cannot be fixed by a patch or minor — confirmed without ambiguity. It's reached through packages/web's own @opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0. For a 0.x dep, caret ^0.203.0 resolves to >=0.203.0 <0.204.0, i.e. patch-only. The core-2.8.0 wave lives at experimental ~0.214.x — roughly eleven minors away and outside the caret. Neither a patch nor a single minor bump within the declared range reaches it; only a deliberate re-pin of those three direct deps to the ~0.214 line would. So a top-level patch/minor genuinely does not solve this chain.

2. core 2.5.1 is partly self-imposed. The hard 2.5.1 floor is this repo's own pre-existing resolutions entry "@opentelemetry/resources": "2.5.1"; Sentry's ^2.5.1 / ^2.5.1 ranges for core/resources/sdk-trace-base already admit 2.8.0 and refresh on their own.

3. core 2.2.0 (posthog-js) and core 2.5.0 (@sentry/node) are the only chains where a top-level minor could theoretically help — but only if a later posthog-js@1.x / @sentry/node@10.x re-bundled the 2.8.0 OTel wave (exporter-logs-otlp-http and instrumentation-http are exact-pinned by them). The lockfile resolves both at 1.369.0 and 10.40.0 respectively, still on the old waves. I could not confirm whether a newer in-range release fixes this, because npm/yarn/WebFetch network access is not permitted in this CI run, so I can't read the latest published manifests.

Bottom line

For the largest blocker (core 2.0.1 via web's own ^0.203.0 deps) I can confirm a patch/minor bump does not resolve it — caret math rules it out. For the @sentry/node and posthog-js chains the mechanism (exact internal pins) makes a patch/minor fix unlikely, but I can't prove it offline. To make this airtight, run from the repo root (needs registry access):

# does any in-range release pull the 2.8.0 wave?
yarn info @sentry/node --json | jq '.children.Version'# latest 10.x
yarn info posthog-js --json | jq '.children.Version'# latest 1.x# then, with the resolutions removed, refresh top-levels and inspect:
yarn up '@sentry/node@^10''posthog-js@^1'&& yarn why @opentelemetry/core --recursive

If those still show any @opentelemetry/core < 2.8.0, the qualified resolutions in this PR are the correct fix. The one cleanup worth considering regardless: the packages/web@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0 deps are direct and quite stale — bumping them to the current ~0.214 line would remove the 2.0.1 chain at the source rather than via an override.

Note: I was unable to run npm/yarn/WebFetch in this run (permissions not granted), so the Sentry/posthog conclusions are structural rather than empirically reproduced. If you re-run me with those tools allowed, I can produce the live yarn why output.
• linear/sou-1359-sourcebot-devsourcebot-cve-2026-54285-opentelemetry-7cd4

[linear-code]

Fixes SOU-1359

Addresses CVE-2026-54285 (unbounded memory allocation in W3C Baggage propagation, @opentelemetry/core < 2.8.0).

Refreshing the lockfile (yarn up -R @opentelemetry/core) bumped the caret-ranged requesters to 2.8.0, but several deep transitive packages under @sentry/node and posthog-js pin @opentelemetry/core to exact versions (2.0.1, 2.2.0, 2.5.0, 2.5.1). Since no single top-level bump covers all of these, qualified resolutions overrides pin each to ^2.8.0. All instances now resolve to 2.8.0 (verified via yarn why @opentelemetry/core --recursive).

[github-actions]

License Audit

❌ Audit failed to produce results. Check the workflow logs for details.

[brendan-kellam]

@claude can you cross-validate that bumping the top level packages by either a patch or a minor would not solve this issue?

[claude]

Claude finished @brendan-kellam's task in 5m 2s —— View job

---

Cross-validation: can a top-level patch/minor bump avoid the resolutions overrides?

• Identify top-level packages that pull in @opentelemetry/core
• Trace the transitive chains to the pinned 2.0.1 / 2.2.0 / 2.5.0 / 2.5.1 versions
• Check whether a patch/minor bump of each top-level package lifts those pins to ≥ 2.8.0
• Report findings

Why the deep pins are sticky

Every blocked version comes from an OpenTelemetry package that pins @opentelemetry/core to an exact version internally (e.g. @opentelemetry/instrumentation-http@0.211.0 → "@opentelemetry/core": "npm:2.5.0", not ^2.5.0). So a given OTel package only stops pulling old core when it advances to the package version from the core-2.8.0 release wave (stable 2.8.0 ↔ experimental ~0.214.x). A top-level bump helps only if a reachable patch/minor re-bundles that wave.

Ownership of each pin (traced from origin/mainyarn.lock)

Pinned core	Pulled in by (exact requester)	Top-level owner & range	Patch/minor fixes it?
2.0.1	@opentelemetry/sdk-logs@0.203.0, instrumentation@0.203.0, api-logs@0.203.0	packages/web direct deps@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0	No — provably
2.2.0	@opentelemetry/exporter-logs-otlp-http@^0.208.0 + the 0.208.0/2.2.0 wave	posthog-js@^1.369.0; also @fastify/otel@0.16.0 (pinned by Sentry)	Unverifiable offline
2.5.0	@opentelemetry/instrumentation-http@0.211.0 (exact)	@sentry/node@^10.40.0 (+ nextjs/profiling-node)	Unverifiable offline
2.5.1	@opentelemetry/resources@2.5.1; sdk-trace-base@^2.5.1	root resolutions override"@opentelemetry/resources": "2.5.1" + Sentry's ^2.5.1 (caret already admits 2.8.0)	Self-imposed

Findings

1. core 2.0.1 cannot be fixed by a patch or minor — confirmed without ambiguity. It's reached through packages/web's own @opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0. For a 0.x dep, caret ^0.203.0 resolves to >=0.203.0 <0.204.0, i.e. patch-only. The core-2.8.0 wave lives at experimental ~0.214.x — roughly eleven minors away and outside the caret. Neither a patch nor a single minor bump within the declared range reaches it; only a deliberate re-pin of those three direct deps to the ~0.214 line would. So a top-level patch/minor genuinely does not solve this chain.

2. core 2.5.1 is partly self-imposed. The hard 2.5.1 floor is this repo's own pre-existing resolutions entry "@opentelemetry/resources": "2.5.1"; Sentry's ^2.5.1 / ^2.5.1 ranges for core/resources/sdk-trace-base already admit 2.8.0 and refresh on their own.

3. core 2.2.0 (posthog-js) and core 2.5.0 (@sentry/node) are the only chains where a top-level minor could theoretically help — but only if a later posthog-js@1.x / @sentry/node@10.x re-bundled the 2.8.0 OTel wave (exporter-logs-otlp-http and instrumentation-http are exact-pinned by them). The lockfile resolves both at 1.369.0 and 10.40.0 respectively, still on the old waves. I could not confirm whether a newer in-range release fixes this, because npm/yarn/WebFetch network access is not permitted in this CI run, so I can't read the latest published manifests.

Bottom line

For the largest blocker (core 2.0.1 via web's own ^0.203.0 deps) I can confirm a patch/minor bump does not resolve it — caret math rules it out. For the @sentry/node and posthog-js chains the mechanism (exact internal pins) makes a patch/minor fix unlikely, but I can't prove it offline. To make this airtight, run from the repo root (needs registry access):

# does any in-range release pull the 2.8.0 wave?
yarn info @sentry/node --json | jq '.children.Version'# latest 10.x
yarn info posthog-js --json | jq '.children.Version'# latest 1.x# then, with the resolutions removed, refresh top-levels and inspect:
yarn up '@sentry/node@^10''posthog-js@^1'&& yarn why @opentelemetry/core --recursive

If those still show any @opentelemetry/core < 2.8.0, the qualified resolutions in this PR are the correct fix. The one cleanup worth considering regardless: the packages/web@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0 deps are direct and quite stale — bumping them to the current ~0.214 line would remove the 2.0.1 chain at the source rather than via an override.

Note: I was unable to run npm/yarn/WebFetch in this run (permissions not granted), so the Sentry/posthog conclusions are structural rather than empirically reproduced. If you re-run me with those tools allowed, I can produce the live yarn why output.
• linear/sou-1359-sourcebot-devsourcebot-cve-2026-54285-opentelemetry-7cd4

[linear-code]

Fixes SOU-1359

Addresses CVE-2026-54285 (unbounded memory allocation in W3C Baggage propagation, @opentelemetry/core < 2.8.0).

Refreshing the lockfile (yarn up -R @opentelemetry/core) bumped the caret-ranged requesters to 2.8.0, but several deep transitive packages under @sentry/node and posthog-js pin @opentelemetry/core to exact versions (2.0.1, 2.2.0, 2.5.0, 2.5.1). Since no single top-level bump covers all of these, qualified resolutions overrides pin each to ^2.8.0. All instances now resolve to 2.8.0 (verified via yarn why @opentelemetry/core --recursive).

[github-actions]

License Audit

❌ Audit failed to produce results. Check the workflow logs for details.

[brendan-kellam]

@claude can you cross-validate that bumping the top level packages by either a patch or a minor would not solve this issue?

[claude]

Claude finished @brendan-kellam's task in 5m 2s —— View job

---

Cross-validation: can a top-level patch/minor bump avoid the resolutions overrides?

• Identify top-level packages that pull in @opentelemetry/core
• Trace the transitive chains to the pinned 2.0.1 / 2.2.0 / 2.5.0 / 2.5.1 versions
• Check whether a patch/minor bump of each top-level package lifts those pins to ≥ 2.8.0
• Report findings

Why the deep pins are sticky

Every blocked version comes from an OpenTelemetry package that pins @opentelemetry/core to an exact version internally (e.g. @opentelemetry/instrumentation-http@0.211.0 → "@opentelemetry/core": "npm:2.5.0", not ^2.5.0). So a given OTel package only stops pulling old core when it advances to the package version from the core-2.8.0 release wave (stable 2.8.0 ↔ experimental ~0.214.x). A top-level bump helps only if a reachable patch/minor re-bundles that wave.

Ownership of each pin (traced from origin/mainyarn.lock)

Pinned core	Pulled in by (exact requester)	Top-level owner & range	Patch/minor fixes it?
2.0.1	@opentelemetry/sdk-logs@0.203.0, instrumentation@0.203.0, api-logs@0.203.0	packages/web direct deps@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0	No — provably
2.2.0	@opentelemetry/exporter-logs-otlp-http@^0.208.0 + the 0.208.0/2.2.0 wave	posthog-js@^1.369.0; also @fastify/otel@0.16.0 (pinned by Sentry)	Unverifiable offline
2.5.0	@opentelemetry/instrumentation-http@0.211.0 (exact)	@sentry/node@^10.40.0 (+ nextjs/profiling-node)	Unverifiable offline
2.5.1	@opentelemetry/resources@2.5.1; sdk-trace-base@^2.5.1	root resolutions override"@opentelemetry/resources": "2.5.1" + Sentry's ^2.5.1 (caret already admits 2.8.0)	Self-imposed

Findings

1. core 2.0.1 cannot be fixed by a patch or minor — confirmed without ambiguity. It's reached through packages/web's own @opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0. For a 0.x dep, caret ^0.203.0 resolves to >=0.203.0 <0.204.0, i.e. patch-only. The core-2.8.0 wave lives at experimental ~0.214.x — roughly eleven minors away and outside the caret. Neither a patch nor a single minor bump within the declared range reaches it; only a deliberate re-pin of those three direct deps to the ~0.214 line would. So a top-level patch/minor genuinely does not solve this chain.

2. core 2.5.1 is partly self-imposed. The hard 2.5.1 floor is this repo's own pre-existing resolutions entry "@opentelemetry/resources": "2.5.1"; Sentry's ^2.5.1 / ^2.5.1 ranges for core/resources/sdk-trace-base already admit 2.8.0 and refresh on their own.

3. core 2.2.0 (posthog-js) and core 2.5.0 (@sentry/node) are the only chains where a top-level minor could theoretically help — but only if a later posthog-js@1.x / @sentry/node@10.x re-bundled the 2.8.0 OTel wave (exporter-logs-otlp-http and instrumentation-http are exact-pinned by them). The lockfile resolves both at 1.369.0 and 10.40.0 respectively, still on the old waves. I could not confirm whether a newer in-range release fixes this, because npm/yarn/WebFetch network access is not permitted in this CI run, so I can't read the latest published manifests.

Bottom line

For the largest blocker (core 2.0.1 via web's own ^0.203.0 deps) I can confirm a patch/minor bump does not resolve it — caret math rules it out. For the @sentry/node and posthog-js chains the mechanism (exact internal pins) makes a patch/minor fix unlikely, but I can't prove it offline. To make this airtight, run from the repo root (needs registry access):

# does any in-range release pull the 2.8.0 wave?
yarn info @sentry/node --json | jq '.children.Version'# latest 10.x
yarn info posthog-js --json | jq '.children.Version'# latest 1.x# then, with the resolutions removed, refresh top-levels and inspect:
yarn up '@sentry/node@^10''posthog-js@^1'&& yarn why @opentelemetry/core --recursive

If those still show any @opentelemetry/core < 2.8.0, the qualified resolutions in this PR are the correct fix. The one cleanup worth considering regardless: the packages/web@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0 deps are direct and quite stale — bumping them to the current ~0.214 line would remove the 2.0.1 chain at the source rather than via an override.

Note: I was unable to run npm/yarn/WebFetch in this run (permissions not granted), so the Sentry/posthog conclusions are structural rather than empirically reproduced. If you re-run me with those tools allowed, I can produce the live yarn why output.
• linear/sou-1359-sourcebot-devsourcebot-cve-2026-54285-opentelemetry-7cd4

[linear-code]

Fixes SOU-1359

Addresses CVE-2026-54285 (unbounded memory allocation in W3C Baggage propagation, @opentelemetry/core < 2.8.0).

Refreshing the lockfile (yarn up -R @opentelemetry/core) bumped the caret-ranged requesters to 2.8.0, but several deep transitive packages under @sentry/node and posthog-js pin @opentelemetry/core to exact versions (2.0.1, 2.2.0, 2.5.0, 2.5.1). Since no single top-level bump covers all of these, qualified resolutions overrides pin each to ^2.8.0. All instances now resolve to 2.8.0 (verified via yarn why @opentelemetry/core --recursive).

[github-actions]

License Audit

❌ Audit failed to produce results. Check the workflow logs for details.

[brendan-kellam]

@claude can you cross-validate that bumping the top level packages by either a patch or a minor would not solve this issue?

[claude]

Claude finished @brendan-kellam's task in 5m 2s —— View job

---

Cross-validation: can a top-level patch/minor bump avoid the resolutions overrides?

• Identify top-level packages that pull in @opentelemetry/core
• Trace the transitive chains to the pinned 2.0.1 / 2.2.0 / 2.5.0 / 2.5.1 versions
• Check whether a patch/minor bump of each top-level package lifts those pins to ≥ 2.8.0
• Report findings

Why the deep pins are sticky

Every blocked version comes from an OpenTelemetry package that pins @opentelemetry/core to an exact version internally (e.g. @opentelemetry/instrumentation-http@0.211.0 → "@opentelemetry/core": "npm:2.5.0", not ^2.5.0). So a given OTel package only stops pulling old core when it advances to the package version from the core-2.8.0 release wave (stable 2.8.0 ↔ experimental ~0.214.x). A top-level bump helps only if a reachable patch/minor re-bundles that wave.

Ownership of each pin (traced from origin/mainyarn.lock)

Pinned core	Pulled in by (exact requester)	Top-level owner & range	Patch/minor fixes it?
2.0.1	@opentelemetry/sdk-logs@0.203.0, instrumentation@0.203.0, api-logs@0.203.0	packages/web direct deps@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0	No — provably
2.2.0	@opentelemetry/exporter-logs-otlp-http@^0.208.0 + the 0.208.0/2.2.0 wave	posthog-js@^1.369.0; also @fastify/otel@0.16.0 (pinned by Sentry)	Unverifiable offline
2.5.0	@opentelemetry/instrumentation-http@0.211.0 (exact)	@sentry/node@^10.40.0 (+ nextjs/profiling-node)	Unverifiable offline
2.5.1	@opentelemetry/resources@2.5.1; sdk-trace-base@^2.5.1	root resolutions override"@opentelemetry/resources": "2.5.1" + Sentry's ^2.5.1 (caret already admits 2.8.0)	Self-imposed

Findings

1. core 2.0.1 cannot be fixed by a patch or minor — confirmed without ambiguity. It's reached through packages/web's own @opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0. For a 0.x dep, caret ^0.203.0 resolves to >=0.203.0 <0.204.0, i.e. patch-only. The core-2.8.0 wave lives at experimental ~0.214.x — roughly eleven minors away and outside the caret. Neither a patch nor a single minor bump within the declared range reaches it; only a deliberate re-pin of those three direct deps to the ~0.214 line would. So a top-level patch/minor genuinely does not solve this chain.

2. core 2.5.1 is partly self-imposed. The hard 2.5.1 floor is this repo's own pre-existing resolutions entry "@opentelemetry/resources": "2.5.1"; Sentry's ^2.5.1 / ^2.5.1 ranges for core/resources/sdk-trace-base already admit 2.8.0 and refresh on their own.

3. core 2.2.0 (posthog-js) and core 2.5.0 (@sentry/node) are the only chains where a top-level minor could theoretically help — but only if a later posthog-js@1.x / @sentry/node@10.x re-bundled the 2.8.0 OTel wave (exporter-logs-otlp-http and instrumentation-http are exact-pinned by them). The lockfile resolves both at 1.369.0 and 10.40.0 respectively, still on the old waves. I could not confirm whether a newer in-range release fixes this, because npm/yarn/WebFetch network access is not permitted in this CI run, so I can't read the latest published manifests.

Bottom line

For the largest blocker (core 2.0.1 via web's own ^0.203.0 deps) I can confirm a patch/minor bump does not resolve it — caret math rules it out. For the @sentry/node and posthog-js chains the mechanism (exact internal pins) makes a patch/minor fix unlikely, but I can't prove it offline. To make this airtight, run from the repo root (needs registry access):

# does any in-range release pull the 2.8.0 wave?
yarn info @sentry/node --json | jq '.children.Version'# latest 10.x
yarn info posthog-js --json | jq '.children.Version'# latest 1.x# then, with the resolutions removed, refresh top-levels and inspect:
yarn up '@sentry/node@^10''posthog-js@^1'&& yarn why @opentelemetry/core --recursive

If those still show any @opentelemetry/core < 2.8.0, the qualified resolutions in this PR are the correct fix. The one cleanup worth considering regardless: the packages/web@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0 deps are direct and quite stale — bumping them to the current ~0.214 line would remove the 2.0.1 chain at the source rather than via an override.

Note: I was unable to run npm/yarn/WebFetch in this run (permissions not granted), so the Sentry/posthog conclusions are structural rather than empirically reproduced. If you re-run me with those tools allowed, I can produce the live yarn why output.
• linear/sou-1359-sourcebot-devsourcebot-cve-2026-54285-opentelemetry-7cd4

[linear-code]

Fixes SOU-1359

Addresses CVE-2026-54285 (unbounded memory allocation in W3C Baggage propagation, @opentelemetry/core < 2.8.0).

Refreshing the lockfile (yarn up -R @opentelemetry/core) bumped the caret-ranged requesters to 2.8.0, but several deep transitive packages under @sentry/node and posthog-js pin @opentelemetry/core to exact versions (2.0.1, 2.2.0, 2.5.0, 2.5.1). Since no single top-level bump covers all of these, qualified resolutions overrides pin each to ^2.8.0. All instances now resolve to 2.8.0 (verified via yarn why @opentelemetry/core --recursive).

[github-actions]

License Audit

❌ Audit failed to produce results. Check the workflow logs for details.

[brendan-kellam]

@claude can you cross-validate that bumping the top level packages by either a patch or a minor would not solve this issue?

[claude]

Claude finished @brendan-kellam's task in 5m 2s —— View job

---

Cross-validation: can a top-level patch/minor bump avoid the resolutions overrides?

• Identify top-level packages that pull in @opentelemetry/core
• Trace the transitive chains to the pinned 2.0.1 / 2.2.0 / 2.5.0 / 2.5.1 versions
• Check whether a patch/minor bump of each top-level package lifts those pins to ≥ 2.8.0
• Report findings

Why the deep pins are sticky

Every blocked version comes from an OpenTelemetry package that pins @opentelemetry/core to an exact version internally (e.g. @opentelemetry/instrumentation-http@0.211.0 → "@opentelemetry/core": "npm:2.5.0", not ^2.5.0). So a given OTel package only stops pulling old core when it advances to the package version from the core-2.8.0 release wave (stable 2.8.0 ↔ experimental ~0.214.x). A top-level bump helps only if a reachable patch/minor re-bundles that wave.

Ownership of each pin (traced from origin/mainyarn.lock)

Pinned core	Pulled in by (exact requester)	Top-level owner & range	Patch/minor fixes it?
2.0.1	@opentelemetry/sdk-logs@0.203.0, instrumentation@0.203.0, api-logs@0.203.0	packages/web direct deps@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0	No — provably
2.2.0	@opentelemetry/exporter-logs-otlp-http@^0.208.0 + the 0.208.0/2.2.0 wave	posthog-js@^1.369.0; also @fastify/otel@0.16.0 (pinned by Sentry)	Unverifiable offline
2.5.0	@opentelemetry/instrumentation-http@0.211.0 (exact)	@sentry/node@^10.40.0 (+ nextjs/profiling-node)	Unverifiable offline
2.5.1	@opentelemetry/resources@2.5.1; sdk-trace-base@^2.5.1	root resolutions override"@opentelemetry/resources": "2.5.1" + Sentry's ^2.5.1 (caret already admits 2.8.0)	Self-imposed

Findings

1. core 2.0.1 cannot be fixed by a patch or minor — confirmed without ambiguity. It's reached through packages/web's own @opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0. For a 0.x dep, caret ^0.203.0 resolves to >=0.203.0 <0.204.0, i.e. patch-only. The core-2.8.0 wave lives at experimental ~0.214.x — roughly eleven minors away and outside the caret. Neither a patch nor a single minor bump within the declared range reaches it; only a deliberate re-pin of those three direct deps to the ~0.214 line would. So a top-level patch/minor genuinely does not solve this chain.

2. core 2.5.1 is partly self-imposed. The hard 2.5.1 floor is this repo's own pre-existing resolutions entry "@opentelemetry/resources": "2.5.1"; Sentry's ^2.5.1 / ^2.5.1 ranges for core/resources/sdk-trace-base already admit 2.8.0 and refresh on their own.

3. core 2.2.0 (posthog-js) and core 2.5.0 (@sentry/node) are the only chains where a top-level minor could theoretically help — but only if a later posthog-js@1.x / @sentry/node@10.x re-bundled the 2.8.0 OTel wave (exporter-logs-otlp-http and instrumentation-http are exact-pinned by them). The lockfile resolves both at 1.369.0 and 10.40.0 respectively, still on the old waves. I could not confirm whether a newer in-range release fixes this, because npm/yarn/WebFetch network access is not permitted in this CI run, so I can't read the latest published manifests.

Bottom line

For the largest blocker (core 2.0.1 via web's own ^0.203.0 deps) I can confirm a patch/minor bump does not resolve it — caret math rules it out. For the @sentry/node and posthog-js chains the mechanism (exact internal pins) makes a patch/minor fix unlikely, but I can't prove it offline. To make this airtight, run from the repo root (needs registry access):

# does any in-range release pull the 2.8.0 wave?
yarn info @sentry/node --json | jq '.children.Version'# latest 10.x
yarn info posthog-js --json | jq '.children.Version'# latest 1.x# then, with the resolutions removed, refresh top-levels and inspect:
yarn up '@sentry/node@^10''posthog-js@^1'&& yarn why @opentelemetry/core --recursive

If those still show any @opentelemetry/core < 2.8.0, the qualified resolutions in this PR are the correct fix. The one cleanup worth considering regardless: the packages/web@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0 deps are direct and quite stale — bumping them to the current ~0.214 line would remove the 2.0.1 chain at the source rather than via an override.

Note: I was unable to run npm/yarn/WebFetch in this run (permissions not granted), so the Sentry/posthog conclusions are structural rather than empirically reproduced. If you re-run me with those tools allowed, I can produce the live yarn why output.
• linear/sou-1359-sourcebot-devsourcebot-cve-2026-54285-opentelemetry-7cd4

[linear-code]

Fixes SOU-1359

Addresses CVE-2026-54285 (unbounded memory allocation in W3C Baggage propagation, @opentelemetry/core < 2.8.0).

Refreshing the lockfile (yarn up -R @opentelemetry/core) bumped the caret-ranged requesters to 2.8.0, but several deep transitive packages under @sentry/node and posthog-js pin @opentelemetry/core to exact versions (2.0.1, 2.2.0, 2.5.0, 2.5.1). Since no single top-level bump covers all of these, qualified resolutions overrides pin each to ^2.8.0. All instances now resolve to 2.8.0 (verified via yarn why @opentelemetry/core --recursive).

[github-actions]

License Audit

❌ Audit failed to produce results. Check the workflow logs for details.

[brendan-kellam]

@claude can you cross-validate that bumping the top level packages by either a patch or a minor would not solve this issue?

[claude]

Claude finished @brendan-kellam's task in 5m 2s —— View job

---

Cross-validation: can a top-level patch/minor bump avoid the resolutions overrides?

• Identify top-level packages that pull in @opentelemetry/core
• Trace the transitive chains to the pinned 2.0.1 / 2.2.0 / 2.5.0 / 2.5.1 versions
• Check whether a patch/minor bump of each top-level package lifts those pins to ≥ 2.8.0
• Report findings

Why the deep pins are sticky

Every blocked version comes from an OpenTelemetry package that pins @opentelemetry/core to an exact version internally (e.g. @opentelemetry/instrumentation-http@0.211.0 → "@opentelemetry/core": "npm:2.5.0", not ^2.5.0). So a given OTel package only stops pulling old core when it advances to the package version from the core-2.8.0 release wave (stable 2.8.0 ↔ experimental ~0.214.x). A top-level bump helps only if a reachable patch/minor re-bundles that wave.

Ownership of each pin (traced from origin/mainyarn.lock)

Pinned core	Pulled in by (exact requester)	Top-level owner & range	Patch/minor fixes it?
2.0.1	@opentelemetry/sdk-logs@0.203.0, instrumentation@0.203.0, api-logs@0.203.0	packages/web direct deps@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0	No — provably
2.2.0	@opentelemetry/exporter-logs-otlp-http@^0.208.0 + the 0.208.0/2.2.0 wave	posthog-js@^1.369.0; also @fastify/otel@0.16.0 (pinned by Sentry)	Unverifiable offline
2.5.0	@opentelemetry/instrumentation-http@0.211.0 (exact)	@sentry/node@^10.40.0 (+ nextjs/profiling-node)	Unverifiable offline
2.5.1	@opentelemetry/resources@2.5.1; sdk-trace-base@^2.5.1	root resolutions override"@opentelemetry/resources": "2.5.1" + Sentry's ^2.5.1 (caret already admits 2.8.0)	Self-imposed

Findings

1. core 2.0.1 cannot be fixed by a patch or minor — confirmed without ambiguity. It's reached through packages/web's own @opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0. For a 0.x dep, caret ^0.203.0 resolves to >=0.203.0 <0.204.0, i.e. patch-only. The core-2.8.0 wave lives at experimental ~0.214.x — roughly eleven minors away and outside the caret. Neither a patch nor a single minor bump within the declared range reaches it; only a deliberate re-pin of those three direct deps to the ~0.214 line would. So a top-level patch/minor genuinely does not solve this chain.

2. core 2.5.1 is partly self-imposed. The hard 2.5.1 floor is this repo's own pre-existing resolutions entry "@opentelemetry/resources": "2.5.1"; Sentry's ^2.5.1 / ^2.5.1 ranges for core/resources/sdk-trace-base already admit 2.8.0 and refresh on their own.

3. core 2.2.0 (posthog-js) and core 2.5.0 (@sentry/node) are the only chains where a top-level minor could theoretically help — but only if a later posthog-js@1.x / @sentry/node@10.x re-bundled the 2.8.0 OTel wave (exporter-logs-otlp-http and instrumentation-http are exact-pinned by them). The lockfile resolves both at 1.369.0 and 10.40.0 respectively, still on the old waves. I could not confirm whether a newer in-range release fixes this, because npm/yarn/WebFetch network access is not permitted in this CI run, so I can't read the latest published manifests.

Bottom line

For the largest blocker (core 2.0.1 via web's own ^0.203.0 deps) I can confirm a patch/minor bump does not resolve it — caret math rules it out. For the @sentry/node and posthog-js chains the mechanism (exact internal pins) makes a patch/minor fix unlikely, but I can't prove it offline. To make this airtight, run from the repo root (needs registry access):

# does any in-range release pull the 2.8.0 wave?
yarn info @sentry/node --json | jq '.children.Version'# latest 10.x
yarn info posthog-js --json | jq '.children.Version'# latest 1.x# then, with the resolutions removed, refresh top-levels and inspect:
yarn up '@sentry/node@^10''posthog-js@^1'&& yarn why @opentelemetry/core --recursive

If those still show any @opentelemetry/core < 2.8.0, the qualified resolutions in this PR are the correct fix. The one cleanup worth considering regardless: the packages/web@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0 deps are direct and quite stale — bumping them to the current ~0.214 line would remove the 2.0.1 chain at the source rather than via an override.

Note: I was unable to run npm/yarn/WebFetch in this run (permissions not granted), so the Sentry/posthog conclusions are structural rather than empirically reproduced. If you re-run me with those tools allowed, I can produce the live yarn why output.
• linear/sou-1359-sourcebot-devsourcebot-cve-2026-54285-opentelemetry-7cd4

[linear-code]

Fixes SOU-1359

Addresses CVE-2026-54285 (unbounded memory allocation in W3C Baggage propagation, @opentelemetry/core < 2.8.0).

Refreshing the lockfile (yarn up -R @opentelemetry/core) bumped the caret-ranged requesters to 2.8.0, but several deep transitive packages under @sentry/node and posthog-js pin @opentelemetry/core to exact versions (2.0.1, 2.2.0, 2.5.0, 2.5.1). Since no single top-level bump covers all of these, qualified resolutions overrides pin each to ^2.8.0. All instances now resolve to 2.8.0 (verified via yarn why @opentelemetry/core --recursive).

[github-actions]

License Audit

❌ Audit failed to produce results. Check the workflow logs for details.

[brendan-kellam]

@claude can you cross-validate that bumping the top level packages by either a patch or a minor would not solve this issue?

[claude]

Claude finished @brendan-kellam's task in 5m 2s —— View job

---

Cross-validation: can a top-level patch/minor bump avoid the resolutions overrides?

• Identify top-level packages that pull in @opentelemetry/core
• Trace the transitive chains to the pinned 2.0.1 / 2.2.0 / 2.5.0 / 2.5.1 versions
• Check whether a patch/minor bump of each top-level package lifts those pins to ≥ 2.8.0
• Report findings

Why the deep pins are sticky

Every blocked version comes from an OpenTelemetry package that pins @opentelemetry/core to an exact version internally (e.g. @opentelemetry/instrumentation-http@0.211.0 → "@opentelemetry/core": "npm:2.5.0", not ^2.5.0). So a given OTel package only stops pulling old core when it advances to the package version from the core-2.8.0 release wave (stable 2.8.0 ↔ experimental ~0.214.x). A top-level bump helps only if a reachable patch/minor re-bundles that wave.

Ownership of each pin (traced from origin/mainyarn.lock)

Pinned core	Pulled in by (exact requester)	Top-level owner & range	Patch/minor fixes it?
2.0.1	@opentelemetry/sdk-logs@0.203.0, instrumentation@0.203.0, api-logs@0.203.0	packages/web direct deps@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0	No — provably
2.2.0	@opentelemetry/exporter-logs-otlp-http@^0.208.0 + the 0.208.0/2.2.0 wave	posthog-js@^1.369.0; also @fastify/otel@0.16.0 (pinned by Sentry)	Unverifiable offline
2.5.0	@opentelemetry/instrumentation-http@0.211.0 (exact)	@sentry/node@^10.40.0 (+ nextjs/profiling-node)	Unverifiable offline
2.5.1	@opentelemetry/resources@2.5.1; sdk-trace-base@^2.5.1	root resolutions override"@opentelemetry/resources": "2.5.1" + Sentry's ^2.5.1 (caret already admits 2.8.0)	Self-imposed

Findings

1. core 2.0.1 cannot be fixed by a patch or minor — confirmed without ambiguity. It's reached through packages/web's own @opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0. For a 0.x dep, caret ^0.203.0 resolves to >=0.203.0 <0.204.0, i.e. patch-only. The core-2.8.0 wave lives at experimental ~0.214.x — roughly eleven minors away and outside the caret. Neither a patch nor a single minor bump within the declared range reaches it; only a deliberate re-pin of those three direct deps to the ~0.214 line would. So a top-level patch/minor genuinely does not solve this chain.

2. core 2.5.1 is partly self-imposed. The hard 2.5.1 floor is this repo's own pre-existing resolutions entry "@opentelemetry/resources": "2.5.1"; Sentry's ^2.5.1 / ^2.5.1 ranges for core/resources/sdk-trace-base already admit 2.8.0 and refresh on their own.

3. core 2.2.0 (posthog-js) and core 2.5.0 (@sentry/node) are the only chains where a top-level minor could theoretically help — but only if a later posthog-js@1.x / @sentry/node@10.x re-bundled the 2.8.0 OTel wave (exporter-logs-otlp-http and instrumentation-http are exact-pinned by them). The lockfile resolves both at 1.369.0 and 10.40.0 respectively, still on the old waves. I could not confirm whether a newer in-range release fixes this, because npm/yarn/WebFetch network access is not permitted in this CI run, so I can't read the latest published manifests.

Bottom line

For the largest blocker (core 2.0.1 via web's own ^0.203.0 deps) I can confirm a patch/minor bump does not resolve it — caret math rules it out. For the @sentry/node and posthog-js chains the mechanism (exact internal pins) makes a patch/minor fix unlikely, but I can't prove it offline. To make this airtight, run from the repo root (needs registry access):

# does any in-range release pull the 2.8.0 wave?
yarn info @sentry/node --json | jq '.children.Version'# latest 10.x
yarn info posthog-js --json | jq '.children.Version'# latest 1.x# then, with the resolutions removed, refresh top-levels and inspect:
yarn up '@sentry/node@^10''posthog-js@^1'&& yarn why @opentelemetry/core --recursive

If those still show any @opentelemetry/core < 2.8.0, the qualified resolutions in this PR are the correct fix. The one cleanup worth considering regardless: the packages/web@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0 deps are direct and quite stale — bumping them to the current ~0.214 line would remove the 2.0.1 chain at the source rather than via an override.

Note: I was unable to run npm/yarn/WebFetch in this run (permissions not granted), so the Sentry/posthog conclusions are structural rather than empirically reproduced. If you re-run me with those tools allowed, I can produce the live yarn why output.
• linear/sou-1359-sourcebot-devsourcebot-cve-2026-54285-opentelemetry-7cd4

[linear-code]

Fixes SOU-1359

Addresses CVE-2026-54285 (unbounded memory allocation in W3C Baggage propagation, @opentelemetry/core < 2.8.0).

Refreshing the lockfile (yarn up -R @opentelemetry/core) bumped the caret-ranged requesters to 2.8.0, but several deep transitive packages under @sentry/node and posthog-js pin @opentelemetry/core to exact versions (2.0.1, 2.2.0, 2.5.0, 2.5.1). Since no single top-level bump covers all of these, qualified resolutions overrides pin each to ^2.8.0. All instances now resolve to 2.8.0 (verified via yarn why @opentelemetry/core --recursive).

[github-actions]

License Audit

❌ Audit failed to produce results. Check the workflow logs for details.

[brendan-kellam]

@claude can you cross-validate that bumping the top level packages by either a patch or a minor would not solve this issue?

[claude]

Claude finished @brendan-kellam's task in 5m 2s —— View job

---

Cross-validation: can a top-level patch/minor bump avoid the resolutions overrides?

• Identify top-level packages that pull in @opentelemetry/core
• Trace the transitive chains to the pinned 2.0.1 / 2.2.0 / 2.5.0 / 2.5.1 versions
• Check whether a patch/minor bump of each top-level package lifts those pins to ≥ 2.8.0
• Report findings

Why the deep pins are sticky

Every blocked version comes from an OpenTelemetry package that pins @opentelemetry/core to an exact version internally (e.g. @opentelemetry/instrumentation-http@0.211.0 → "@opentelemetry/core": "npm:2.5.0", not ^2.5.0). So a given OTel package only stops pulling old core when it advances to the package version from the core-2.8.0 release wave (stable 2.8.0 ↔ experimental ~0.214.x). A top-level bump helps only if a reachable patch/minor re-bundles that wave.

Ownership of each pin (traced from origin/mainyarn.lock)

Pinned core	Pulled in by (exact requester)	Top-level owner & range	Patch/minor fixes it?
2.0.1	@opentelemetry/sdk-logs@0.203.0, instrumentation@0.203.0, api-logs@0.203.0	packages/web direct deps@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0	No — provably
2.2.0	@opentelemetry/exporter-logs-otlp-http@^0.208.0 + the 0.208.0/2.2.0 wave	posthog-js@^1.369.0; also @fastify/otel@0.16.0 (pinned by Sentry)	Unverifiable offline
2.5.0	@opentelemetry/instrumentation-http@0.211.0 (exact)	@sentry/node@^10.40.0 (+ nextjs/profiling-node)	Unverifiable offline
2.5.1	@opentelemetry/resources@2.5.1; sdk-trace-base@^2.5.1	root resolutions override"@opentelemetry/resources": "2.5.1" + Sentry's ^2.5.1 (caret already admits 2.8.0)	Self-imposed

Findings

1. core 2.0.1 cannot be fixed by a patch or minor — confirmed without ambiguity. It's reached through packages/web's own @opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0. For a 0.x dep, caret ^0.203.0 resolves to >=0.203.0 <0.204.0, i.e. patch-only. The core-2.8.0 wave lives at experimental ~0.214.x — roughly eleven minors away and outside the caret. Neither a patch nor a single minor bump within the declared range reaches it; only a deliberate re-pin of those three direct deps to the ~0.214 line would. So a top-level patch/minor genuinely does not solve this chain.

2. core 2.5.1 is partly self-imposed. The hard 2.5.1 floor is this repo's own pre-existing resolutions entry "@opentelemetry/resources": "2.5.1"; Sentry's ^2.5.1 / ^2.5.1 ranges for core/resources/sdk-trace-base already admit 2.8.0 and refresh on their own.

3. core 2.2.0 (posthog-js) and core 2.5.0 (@sentry/node) are the only chains where a top-level minor could theoretically help — but only if a later posthog-js@1.x / @sentry/node@10.x re-bundled the 2.8.0 OTel wave (exporter-logs-otlp-http and instrumentation-http are exact-pinned by them). The lockfile resolves both at 1.369.0 and 10.40.0 respectively, still on the old waves. I could not confirm whether a newer in-range release fixes this, because npm/yarn/WebFetch network access is not permitted in this CI run, so I can't read the latest published manifests.

Bottom line

For the largest blocker (core 2.0.1 via web's own ^0.203.0 deps) I can confirm a patch/minor bump does not resolve it — caret math rules it out. For the @sentry/node and posthog-js chains the mechanism (exact internal pins) makes a patch/minor fix unlikely, but I can't prove it offline. To make this airtight, run from the repo root (needs registry access):

# does any in-range release pull the 2.8.0 wave?
yarn info @sentry/node --json | jq '.children.Version'# latest 10.x
yarn info posthog-js --json | jq '.children.Version'# latest 1.x# then, with the resolutions removed, refresh top-levels and inspect:
yarn up '@sentry/node@^10''posthog-js@^1'&& yarn why @opentelemetry/core --recursive

If those still show any @opentelemetry/core < 2.8.0, the qualified resolutions in this PR are the correct fix. The one cleanup worth considering regardless: the packages/web@opentelemetry/{sdk-logs,instrumentation,api-logs}@^0.203.0 deps are direct and quite stale — bumping them to the current ~0.214 line would remove the 2.0.1 chain at the source rather than via an override.

Note: I was unable to run npm/yarn/WebFetch in this run (permissions not granted), so the Sentry/posthog conclusions are structural rather than empirically reproduced. If you re-run me with those tools allowed, I can produce the live yarn why output.
• linear/sou-1359-sourcebot-devsourcebot-cve-2026-54285-opentelemetry-7cd4