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

[FiruzTopher]

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)

[wpessers]

Hi @FiruzTopher, I haven't had a lot of time the past week to do maintenance tasks like dependabot PRs etc. But it's highly likely that this is no longer relevant as soon as I get a bunch of those merged, which I'm hoping to get to tonight. Also be aware that reporting such a cve through an issue isn't as useful as submitting an actual vulnerability: https://github.com/open-telemetry/opentelemetry-lambda/security/policy since only the latter would get picked up by scanners, like dependabot in our case.

[FiruzTopher]

Hey @wpessers thanks a lot for the feedback.
I do this as part of our security policy, in an attempt to centralize requests and validate our assessment.

The security reporting way you mentioned is private, which might cause duplicate reports and effort on your end.

Either way is fine for me in the future, do you have a preference?

[wpessers]

Doesn't matter that much, if it's purely for tracking on your end don't worry about it. As I said I'll take a look tonight but I suspect we'll already have an automatically reported vulnerability matching this one.

[wpessers]

I agree the vulnerability is indeed highly unlikely to have any practical impact. However, I'll leave this issue open until we do have a more recent version of golang.org/x/net >= v0.55.0