Problem
We pin the OpenTelemetry family at 1.12.0 (1.11.x in Beamable.Tooling.Common). Two advisories landed against those versions in April 2026:
Two more exporter advisories (GHSA-q834-8qmm-v933, GHSA-mr8r-92fq-pj8p, both DoS via unbounded response parsing) also cover 1.12.0 and are fixed in 1.15.2 / 1.15.3. The customer screenshot did not list them, but a scanner will once its feed catches up.
Pins live in four files:
microservice/microservice/microservice.csproj (1.12.0, plus Instrumentation.Process 1.12.0-beta.1 and Instrumentation.Runtime 1.12.0)
microservice/beamable.tooling.common/beamable.tooling.common.csproj (1.11.1 / 1.11.0-beta.1 / 1.11.0)
cli/beamable.microservice.otel.exporter/beamable.microservice.otel.exporter.csproj (1.12.0)
cli/beamable.otel.common/beamable.otel.common.csproj (1.12.0)
Impact
Two yellow "contains vulnerabilities" warnings in every customer C#MS (Barnstorm, 2 Sep 2026). The Api advisory is the one with a real surface: oversized W3C or Baggage propagation headers from an inbound caller cause disproportionate allocation. A microservice only sees those headers if something in front of it forwards them, so exposure is low but not zero. The exporter advisory only applies when the experimental disk-retry env var is set, which we do not set.
Fix
Move all four csproj files to the same OpenTelemetry version, 1.15.3 or later. Latest stable at time of writing is 1.18.0. Keep the versions aligned across the four projects. The current 1.11 / 1.12 split already means NuGet picks the highest and Tooling.Common is compiled against an older API than it runs on.
OpenTelemetry.Instrumentation.Process is still pre-release on our side (1.12.0-beta.1). Check whether a stable line exists at the target version before bumping it.
Proof to close
dotnet list package --vulnerable --include-transitive on a fresh service shows no OpenTelemetry entries.
- Telemetry still reaches the collector and Clickhouse from a locally run service and from a deployed one. The OTLP exporter is the piece that actually changes here, so watch the collector logs for protocol errors.
Problem
We pin the OpenTelemetry family at 1.12.0 (1.11.x in
Beamable.Tooling.Common). Two advisories landed against those versions in April 2026:Two more exporter advisories (GHSA-q834-8qmm-v933, GHSA-mr8r-92fq-pj8p, both DoS via unbounded response parsing) also cover 1.12.0 and are fixed in 1.15.2 / 1.15.3. The customer screenshot did not list them, but a scanner will once its feed catches up.
Pins live in four files:
microservice/microservice/microservice.csproj(1.12.0, plus Instrumentation.Process 1.12.0-beta.1 and Instrumentation.Runtime 1.12.0)microservice/beamable.tooling.common/beamable.tooling.common.csproj(1.11.1 / 1.11.0-beta.1 / 1.11.0)cli/beamable.microservice.otel.exporter/beamable.microservice.otel.exporter.csproj(1.12.0)cli/beamable.otel.common/beamable.otel.common.csproj(1.12.0)Impact
Two yellow "contains vulnerabilities" warnings in every customer C#MS (Barnstorm, 2 Sep 2026). The Api advisory is the one with a real surface: oversized W3C or Baggage propagation headers from an inbound caller cause disproportionate allocation. A microservice only sees those headers if something in front of it forwards them, so exposure is low but not zero. The exporter advisory only applies when the experimental disk-retry env var is set, which we do not set.
Fix
Move all four csproj files to the same OpenTelemetry version, 1.15.3 or later. Latest stable at time of writing is 1.18.0. Keep the versions aligned across the four projects. The current 1.11 / 1.12 split already means NuGet picks the highest and Tooling.Common is compiled against an older API than it runs on.
OpenTelemetry.Instrumentation.Processis still pre-release on our side (1.12.0-beta.1). Check whether a stable line exists at the target version before bumping it.Proof to close
dotnet list package --vulnerable --include-transitiveon a fresh service shows no OpenTelemetry entries.