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

オープン
  • 何か問題がありますか？
#2,323 コメント 5 件 リアクション 3 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
aws, go
領域
build-system, cloud, security

調査の方向性

Issue で言及されている layer-collector/0.22.0 の参照時点にある collector/lambdacomponents/go.mod から始め、collector Lambda layer のビルド方法とリリース方法を確認します。依存関係が golang.org/x/net v0.55.0 以降に到達していることを確認し、影響を受ける layer を再ビルドします。layer に脆弱なバージョンが含まれなくなれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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)

主要言語
Go
スター
433
フォーク
249
平均マージ
1日 12時間
マージ済み PR（30日）
39

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

open-telemetry/opentelemetry-lambda のほかの issue

open-telemetry/opentelemetry-lambda の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。