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

Abierto
  • ¿Algo no está bien?
#2,323 5 comentarios 3 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
aws, go
Área
build-system, cloud, security

Línea de trabajo

Comienza con collector/lambdacomponents/go.mod en la referencia layer-collector/0.22.0 mencionada en el issue y, después, inspecciona cómo se compila y publica la capa Lambda del collector. Confirma que la dependencia alcanza golang.org/x/net v0.55.0 o posterior y vuelve a compilar la capa afectada; se considera terminado cuando la capa ya no contiene la versión vulnerable.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)

Lenguaje dominante
Go
Estrellas
433
Forks
249
Merge medio
1 d 12 h
PR fusionados (30 d)
39

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de open-telemetry/opentelemetry-lambda

Todos los issues de open-telemetry/opentelemetry-lambda

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.