リリース

Prometheus v3.13.0はLTSリリースで、HIGH深刻度の認証情報転送の脆弱性(CVE-2025-4673・CVE-2023-45289)とMEDIUM深刻度のXSS(CVE-2026-44990)への対応を筆頭に、ページネーショントークン、パス解決、PromQL期間関数名、ライセンスファイル配布の4つの破壊的変更、さらに多数の新機能とパフォーマンス改善を含みます。

• securityHIGH: クロスホストリダイレクト時に認証情報が転送されなくなった

  リダイレクト先のホストが異なる場合、Authorizationヘッダー・Basic認証・Bearerトークン・OAuth2・カスタムヘッダーなどの認証情報が転送されなくなりました。スクレイプ・リモートread/write・アラート送信・サービスディスカバリのいずれも対象です。CVE-2025-4673とCVE-2023-45289として追跡されており、prometheus/commonのv0.68.xからv0.69.0への更新が起因です。クロスホストリダイレクトに依存するエンドポイントがあれば、認証情報がサイレントに落ちることを確認してください。

• securityMEDIUM: UI依存ライブラリのXSS修正(CVE-2026-44990)

  UIのsanitize-htmlライブラリにXSS脆弱性(CVE-2026-44990)が存在していたため、バージョンを更新して修正しました。設定変更は不要で、v3.13.0へのアップグレードで対処されます。

• breakingページネーショントークンのアルゴリズムがSHA-1からSHA-256に変更

  ルールグループのページネーショントークン生成がSHA-1からSHA-256に変わりました。旧バージョンで取得したトークンを保持・比較しているクライアントやツールは、アップグレード後に値が変わります。

• breaking--http.config.fileの相対パス解決先が変更

  --http.config.fileに渡すファイル内の相対パスが、親ディレクトリではなくそのconfigファイル自身のディレクトリを基準に解決されるようになりました。相対パスを使っている場合は、アップグレード後にパスが正しく解決されるか確認してください。

• breaking期間表現関数min()/max()がmin_of()/max_of()に改名

  experimental-duration-exprフィーチャーフラグを有効にしている場合、PromQLの期間表現関数min()とmax()がmin_of()とmax_of()に改名されました。これらを使用しているクエリやルールを更新してください。

• breakingnpm_licenses.tar.bz2を廃止、ライセンスは/assets/third-party-licenses.txtへ移行

  リリースtarballおよびコンテナイメージからnpm_licenses.tar.bz2が削除されました。サードパーティnpmライセンス情報はバイナリに埋め込まれ、/assets/third-party-licenses.txtで提供されます。このアーカイブを展開している自動化処理があれば修正が必要です。

Prometheus 3.12.0 ships two security patches (Remote Write DoS, STACKIT SD secret leak), fixes a WAL race in Agent mode, and cuts TSDB range query CPU with a quadratic-to-constant head chunk lookup fix.

• securityPatch two security fixes now — especially if using STACKIT SD

  Two CVEs patched in this release. First: Remote Write now rejects snappy-compressed payloads where the declared decoded size exceeds 32 MB — this closes a DoS vector against your remote-write receiver endpoint. Second: STACKIT SD was leaking secrets in plaintext via the `/-/config` endpoint (GHSA-39j6-789q-qxvh). If you use STACKIT SD, rotate any credentials that may have been exposed before upgrading.

• breakingAgent mode WAL race and remote_write panic bug fixed — upgrade Agent deployments

  A race condition in the agent appender could produce duplicate in-memory series and duplicate WAL records when concurrent appends target the same label set. If you run Prometheus in Agent mode under high write concurrency, this bug could silently corrupt your WAL. Upgrade to 3.12.0 to fix it. Also, `remote_write` queue_config fields are now validated at load time — misconfigurations that previously caused silent runtime panics will now fail at startup, which is the right behavior but means you should test configs before rolling out.

• enhancementTSDB range query CPU cut and auto-reload-config is now stable

  TSDB head chunk lookup in range queries drops from quadratic to constant time, and mmap operations now skip series that don't need work. At production scale with large head chunks, this can meaningfully cut CPU. No config changes needed — just upgrade. Separately, `auto-reload-config` is now stable (no longer experimental), so you can drop any caveats around it in runbooks.

Prometheus v3.11.2 patches a stored XSS vulnerability (CVE-2026-40179) in the web UI, plus two Consul SD fixes. Upgrade immediately if your UI is exposed.

• securityPatch CVE-2026-40179 immediately if your Prometheus UI is reachable

  A stored XSS can be triggered by crafted metric names or label values — meaning any scrape target you ingest data from could potentially inject malicious scripts into your UI. If your Prometheus endpoint is accessible to users beyond the ops team (internal dashboards, federated setups), treat this as urgent. Upgrade to v3.11.2 now. If you can't upgrade immediately, restrict UI access via network policy or auth proxy until you can.

• breakingVerify Consul SD behavior after the Health API filter fix

  The filter parameter was previously applied incorrectly to the Consul Health API. After upgrading, your Consul service discovery results may change if you were relying on that filter — intentionally or not. Review your Consul SD configs and validate that the services being scraped post-upgrade match your expectations before rolling out to production.

• enhancementUse `health_filter` in Consul SD to reduce noise from unhealthy services

  The new `health_filter` field lets you filter Consul Health API responses directly at the SD layer. If you've been working around this with relabeling rules to drop unhealthy instances, you can now clean that up. Set `health_filter` to `healthy` in your Consul SD config to only scrape passing services and reduce unnecessary target churn.

Prometheus v3.11.0 ships significant new discovery capabilities, TSDB experimental features, and a critical retention bug fix that could cause data to be kept 1,000,000x longer than configured.

• breakingFix TSDB retention unit bug before your disk fills up

  A unit mismatch in the config file parser caused `storage.tsdb.retention.time` to be interpreted as 1,000,000x the intended value. If you set retention via the config file (not CLI flags), your TSDB may be holding far more data than expected. Upgrade to 3.11.0 immediately and verify disk usage post-upgrade. Also note: CLI flag values are now the fallback when retention is removed from config, so review your configuration carefully.

• breakingMigrate Hetzner hcloud SD label references before July 2026

  `__meta_hetzner_datacenter` and `__meta_hetzner_hcloud_datacenter_location*` labels are deprecated for hcloud roles and will stop working after July 1, 2026. Audit all relabeling configs and recording rules that reference these labels. Replace with `__meta_hetzner_hcloud_location` and `__meta_hetzner_hcloud_location_network_zone`. The robot role keeps the old label for backward compatibility.

• enhancementCap TSDB disk usage with retention.percentage

  The new `storage.tsdb.retention.percentage` setting lets you define a maximum percentage of available disk that TSDB can use. This is a cleaner safety net than estimating byte-based retention limits, especially in environments with variable data volumes. Consider pairing it with the existing time-based retention rather than replacing it — both constraints apply.