golang.org/x/net - CVE-2026-39821

Hey, I would like to track CVE-2026-39821 here since a scanner raised it in our project as critical.

We use the following relevant OpenTelemetry Lambda layer:

• opentelemetry-collector-arm64-0_22_0:1

The finding is valid at dependency level, but most likely has no practical impact in simple/common AWS Lambda setups, as described below.

Context

ToASCII and ToUnicode incorrectly accepted Punycode-encoded labels that decode to ASCII-only labels. This can lead to privilege escalation in programs that perform security-sensitive checks on ASCII hostnames and later convert them to Unicode. (Go vuln report, Golang announcement, GitHub advisory)

The issue is fixed in golang.org/x/net version v0.55.0. (Go vuln report, Golang announcement)

The currently used collector layer version 0.22.0 contains OpenTelemetry Collector v1.57.0/v0.151.0. (collector layer release)

The relevant collector Lambda module currently references golang.org/x/net v0.53.0, which is below the fixed version. (collector layer go.mod line 244)

Exposure in a simple/common setup

For this assessment, the assumed simple setup is: deployment-controlled local collector configuration, static deployment-controlled exporter endpoints, no user- or tenant-controlled collector configuration, no dynamically generated backend hostnames, and no hostname-based authorization/routing logic in custom collector components.

In a simple/common OpenTelemetry Lambda layer setup, the relevant places where this could matter are:

• opentelemetry-collector-arm64-0_22_0:1

  • This is the affected layer, because it embeds the OpenTelemetry Collector.

• OPENTELEMETRY_COLLECTOR_CONFIG_URI

  • Commonly set to a local file path such as /opt/otel-collector-config.yaml or /var/task/collector.yaml.
  • The collector layer also supports HTTP and S3 URIs for this variable. (collector configuration docs)
  • Risk note: this would be more relevant if collector config was loaded from a remote HTTP/HTTPS/S3 URI and the URI or hostname could be influenced externally.

• Observability backend / OTLP exporter endpoint

  • Used as the OTLP exporter endpoint for the observability backend.
  • Risk note: this would be more relevant if the endpoint hostname was user-controlled, tenant-controlled, request-controlled, or derived from telemetry data.

• Local OTLP receivers

  • The collector receives telemetry from the Lambda instrumentation through OTLP receivers.
  • In the standard Lambda setup this is local communication between the Lambda instrumentation and the collector extension, not a public network endpoint.

In this setup, these values are not derived from Lambda request input, user input, HTTP headers, logs, spans, metrics, or other telemetry payloads.

Therefore, the hostname-related code path described in CVE-2026-39821 does not appear exploitable in a standard/simple OpenTelemetry Lambda layer setup.

Configurations increasing exposure risk

This could become relevant if the setup was changed to use:

• remote collector config via OPENTELEMETRY_COLLECTOR_CONFIG_URI where the URI or hostname is externally influenced
• dynamically generated exporter endpoints
• user- or tenant-controlled observability backend / OTLP exporter endpoint
• hostname allowlist/denylist logic in collector routing
• custom collector components that parse or validate hostnames from telemetry data

Simple setup assessment

So the assessment for the simple/common setup, as described above, is:

Affected dependency present, but no exploitable path identified in the current standard/simple OpenTelemetry Lambda layer configuration. Practical risk is assessed as low pending upgrade.

We are documenting this here for visibility, as automated tooling may flag it as critical without evaluating runtime context.

If your assessment of this issue in a comparable setup differs, please comment.

Remedy

This should be resolved once the OpenTelemetry Lambda collector layer is rebuilt with golang.org/x/net >= v0.55.0. (Go vuln report, Golang announcement)

Start with collector/lambdacomponents/go.mod at the layer-collector/0.22.0 reference mentioned in the issue, then inspect how the collector Lambda layer is built and released. Confirm the dependency reaches golang.org/x/net v0.55.0 or later and rebuild the affected layer; done means the layer no longer contains the vulnerable version.