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

Aperta
  • Qualcosa non va?
#2,323 5 commenti 3 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
aws, go
Ambito
build-system, cloud, security

Direzione di ricerca

Inizia da collector/lambdacomponents/go.mod alla reference layer-collector/0.22.0 menzionata nell’issue, quindi esamina come viene compilato e rilasciato il layer Lambda del collector. Verifica che la dipendenza raggiunga golang.org/x/net v0.55.0 o una versione successiva e ricompila il layer interessato; il lavoro è completato quando il layer non contiene più la versione vulnerabile.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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)

Lingua principale
Go
Stelle
433
Fork
249
Merge medio
1g 12h
PR unite (30g)
39

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di open-telemetry/opentelemetry-lambda

Tutte le issue di open-telemetry/opentelemetry-lambda

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.