Summary
handwritten/pubsub (@google-cloud/pubsub v6.0.0) declares @opentelemetry/core: ^1.30.1. The entire OpenTelemetry JS 1.x line reached end-of-life (~2026-03-17, one year after the 2.0 release), so it will not receive further patches. GHSA-8988-4f7v-96qf / CVE-2026-54285 (unbounded memory allocation in W3CBaggagePropagator.extract()) affects all @opentelemetry/core < 2.8.0, which includes the whole 1.x line. The fix exists only in 2.8.0+, and no 1.x backport will ship because 1.x is EOL.
Because pubsub caps @opentelemetry/core at <2.0.0, every downstream application that installs pubsub has the vulnerable package forced into its tree with no clean remediation — the only workaround is a manual resolutions/override forcing core to 2.8.0+, which shouldn't be necessary for a maintained Google client library.
Why this is a trivial, safe bump (not blocked)
- Node floor is a non-issue. pubsub already sets
"engines": { "node": ">=22" }. OTel core 2.x only requires ^18.19.0 || >=20.6.0, so the 2.x floor is trivially satisfied. (The usual reason libraries stay on core 1.x — preserving Node 14/16 support — does not apply here.)
- Precedent in this very repo.
handwritten/spanner already depends on @opentelemetry/core: ^2.0.0. Same monorepo, same Node policy, same release tooling.
- Minimal API surface. pubsub's only runtime import from
@opentelemetry/core is W3CTraceContextPropagator (handwritten/pubsub/src/telemetry-tracing.ts), which is retained unchanged in core 2.x. @opentelemetry/sdk-trace-base is a devDependency only and does not reach consumers.
Proposed fix
Bump in handwritten/pubsub/package.json:
- "@opentelemetry/core": "^1.30.1",
+ "@opentelemetry/core": "^2.0.0",
(@opentelemetry/api stays ~1.9.0 — it is exempt from the 2.0 breaking changes.)
References
Summary
handwritten/pubsub(@google-cloud/pubsubv6.0.0) declares@opentelemetry/core: ^1.30.1. The entire OpenTelemetry JS1.xline reached end-of-life (~2026-03-17, one year after the 2.0 release), so it will not receive further patches.GHSA-8988-4f7v-96qf/CVE-2026-54285(unbounded memory allocation inW3CBaggagePropagator.extract()) affects all@opentelemetry/core < 2.8.0, which includes the whole1.xline. The fix exists only in2.8.0+, and no1.xbackport will ship because1.xis EOL.Because pubsub caps
@opentelemetry/coreat<2.0.0, every downstream application that installs pubsub has the vulnerable package forced into its tree with no clean remediation — the only workaround is a manualresolutions/override forcing core to2.8.0+, which shouldn't be necessary for a maintained Google client library.Why this is a trivial, safe bump (not blocked)
"engines": { "node": ">=22" }. OTel core 2.x only requires^18.19.0 || >=20.6.0, so the 2.x floor is trivially satisfied. (The usual reason libraries stay on core 1.x — preserving Node 14/16 support — does not apply here.)handwritten/spanneralready depends on@opentelemetry/core: ^2.0.0. Same monorepo, same Node policy, same release tooling.@opentelemetry/coreisW3CTraceContextPropagator(handwritten/pubsub/src/telemetry-tracing.ts), which is retained unchanged in core 2.x.@opentelemetry/sdk-trace-baseis a devDependency only and does not reach consumers.Proposed fix
Bump in
handwritten/pubsub/package.json:(
@opentelemetry/apistays~1.9.0— it is exempt from the 2.0 breaking changes.)References
apiexemption): https://opentelemetry.io/blog/2025/otel-js-sdk-2-0/handwritten/spanner/package.json(@opentelemetry/core: ^2.0.0)