リリース

日本語 準備中v0.151.0 has one API-level breaking change in the OTLP receiver config struct and changes the default behavior of the builder's go.mod generation. Dual-stack gRPC connection fixes and a pprofile data corruption fix are the most operationally relevant improvements.

• breakingUpdate OTLP receiver config field access in custom collectors

  The OTLP receiver's Config.Protocols is now a named field — any code accessing cfg.GRPC or cfg.HTTP directly will fail to compile. Update those references to cfg.Protocols.GRPC and cfg.Protocols.HTTP before upgrading collector builds that embed or extend the OTLP receiver.

• breakingCheck generated collector go.mod if you commit builder output

  cmd/builder now writes relative paths in Go module replace statements by default. For teams that build the collector, commit the generated source, and run it on multiple machines, this is an improvement. If you have tooling that depends on absolute paths (e.g., scripts parsing go.mod), set dist::use_absolute_replace_paths: true to preserve the old behavior while you migrate.

• enhancementFix dual-stack DNS connection issues with passthrough gRPC resolver

  Teams running OTLP gRPC exporters in dual-stack DNS environments have reported connection issues since the grpc.NewClient migration. You can now work around this by setting the endpoint to passthrough:///host:port in your exporter config. If you've seen intermittent connection failures in IPv4/IPv6 mixed environments, try this first.

日本語 準備中v1.120.1 is a patch release focused on carbon cost fixes, AWS Spot pricing performance, memory optimization, and a security-relevant MCP server default change.

• breakingCheck if MCP server was relied upon — it's now off by default

  The MCP server flipped from opt-out to opt-in. If any tooling or integrations depended on the MCP server being active without explicit configuration, they will silently stop working after this upgrade. Before deploying, audit whether MCP_SERVER_ENABLED needs to be explicitly set to true in your environment config.

• enhancementAWS Spot users: Spot Price History caching reduces API pressure

  If you run workloads on AWS Spot instances, OpenCost was previously hitting the Spot Price History API more aggressively. The new caching layer cuts down on AWS API calls, which matters both for rate limiting and for cost attribution latency. No action required, but worth validating your Spot cost data accuracy after upgrading.

• enhancementCarbon cost data was wrong — upgrade if you track emissions

  The carbon cost fixes address incorrect provider detection and broken fallback logic, meaning prior carbon cost figures may have been inaccurate. If you surface carbon/emissions data to teams or dashboards, re-baseline your metrics post-upgrade rather than comparing historical data across this version boundary.

日本語 準備中Prometheus v3.11.3 patches three security vulnerabilities: a credential leak, a DoS vector via malformed snappy payloads, and a stored XSS in the classic UI.

• securityRotate AzureAD client secrets if /-/config was accessible

  If you use AzureAD remote write and the /-/config endpoint was reachable by anyone other than trusted admins, treat your client_secret as compromised. Rotate it in Azure AD immediately, then upgrade to v3.11.3. Also audit who has access to that endpoint — it should never be public-facing.

• securityUpgrade immediately if remote-read is enabled and exposed

  The snappy decode vulnerability lets an attacker send a crafted request with an inflated declared length, potentially exhausting memory. If your Prometheus remote-read endpoint is reachable from outside your trust boundary, this is a real DoS risk. Upgrade to v3.11.3 as soon as possible — there's no config-level workaround short of disabling remote-read entirely.

• securityAssess XSS exposure if you still run the classic UI

  The stored XSS in the old UI heatmap affects any deployment where users can influence label values (e.g., via instrumented applications) and other users view those charts. If you've already migrated to the new UI, you're not affected. If you haven't, upgrade now — or at minimum restrict UI access to trusted users until you do.

日本語 準備中Prometheus v3.5.3 is a security-only release patching four vulnerabilities: credential exposure, two snappy decompression bombs, and a stored XSS in the legacy UI.

• securityRotate AzureAD client_secret immediately if /-/config was exposed

  Any Prometheus instance using AzureAD remote write had its OAuth client_secret visible in plaintext at the /-/config endpoint. If that endpoint was reachable by untrusted users or scraped by monitoring tools, treat the secret as compromised. Rotate it in Azure AD, update your Prometheus config, and then upgrade to v3.5.3. After upgrading, restrict /-/config access via --web.enable-admin-api controls or a reverse proxy allowlist.

• securityUpgrade now if you accept remote-read or remote-write from untrusted sources

  Both remote-read and remote-write endpoints were vulnerable to decompression bomb attacks — a crafted snappy request with an inflated declared size could exhaust memory. If your Prometheus is internet-facing or accepts data from multiple tenants, this is a denial-of-service risk. Upgrade to v3.5.3 immediately. There is no config-level workaround; the fix is in the code.

• securityPatch stored XSS if anyone uses the legacy UI with untrusted label values

  The old UI heatmap rendered 'le' label values without escaping, allowing stored XSS. If your users browse the legacy UI and your metrics include 'le' labels sourced from external or user-controlled systems, malicious JavaScript could execute in their browsers. Upgrade to v3.5.3. As a short-term measure, direct users to the new UI instead.

日本語 準備中Cortex v1.21.0 graduates several experimental features to stable, fixes multiple PRW2 data corruption and panic bugs, and introduces a new Parquet mode for Store Gateway alongside an Overrides API.

• breakingAudit and update renamed flags before upgrading

  Several flags were renamed: -experimental.ruler.enable-api → -ruler.enable-api, -experimental.alertmanager.enable-api → -alertmanager.enable-api, -distributor.otlp.enable-type-and-unit-labels is now a no-op (consolidated into -distributor.enable-type-and-unit-labels), and parquet cache flags/configs dropped 'queryable' from their names. The users-scanner cleanup-interval became update-interval. Old flags are deprecated but not removed yet — audit your config files and Helm values now, before they disappear in a future release.

• breakingPRW2 data corruption and panic fixes require validation of existing pipelines

  Three separate bugs in the Remote Write V2 handler were fixed: shallow copying of Samples/Histograms caused data corruption, dirty sync.Pool reuse caused index-out-of-range panics, and Symbols backing array wasn't cleared on pool return causing memory leaks. If you're using PRW2, treat this upgrade as mandatory. Validate your ingestion pipeline after upgrading and check that downstream metrics are intact.

• enhancementBucket index is now on by default — verify storage permissions

  The bucket index is enabled by default in this release. If your object storage IAM policies restrict list operations or your Cortex deployment had bucket index disabled intentionally, verify that the bucket index can be written and read correctly post-upgrade. Cortex will generate and maintain the index automatically, but storage permission errors will surface as query failures rather than obvious configuration errors.

日本語 準備中Litmus 3.28.0 is a focused maintenance release fixing a probe config leak, a subscriber crash on workflow events, and a Python vulnerability in the frontend base image.

• securityUpgrade frontend to resolve Python CVE in base image

  The frontend container was running on a ubi8 base image with a Python vulnerability. The fix upgrades it to ubi9. If you run Litmus in environments with strict image scanning policies (e.g., Trivy in CI, ACS, or Prisma), this upgrade will clear those alerts. Pull the 3.28.0 frontend image and redeploy — no config changes needed.

• breakingProbe config leak fix may change behavior for shared-type probe setups

  If you run multiple probes of the same type in a single experiment, previous releases silently shared stale config between them. The fix now isolates config per probe. Audit any experiments where multiple probes of the same type are defined — if you were unknowingly relying on config bleed-over, results may differ after upgrading.

• enhancementSubscriber crash fix improves reliability for GitOps and event-driven workflows

  Teams using Litmus in GitOps mode or triggering experiments via Argo Workflow ADD events with ChaosEngine nodes were hitting silent subscriber crashes. After upgrading to 3.28.0, those workflows should resume without manual subscriber restarts. No action required beyond the upgrade, but verify subscriber pod stability post-deploy if you've been seeing unexplained restarts.

日本語 準備中OpenCost v1.120.0 adds OVH cloud provider support, AWS CUR 2.0 compatibility, and fixes several resource leaks and bugs across AWS, DigitalOcean, and S3 integrations.

• breakingCheck PV cost accuracy after upgrading — unit parsing was broken

  PV capacity was previously mishandled for Ki/Mi/Gi/Ti units, which means PV cost allocations may have been wrong in earlier versions. After upgrading, verify your PV cost data looks correct, especially if you were seeing anomalous persistent volume costs.

• enhancementMigrate to AWS CUR 2.0 if you haven't already

  AWS is deprecating CUR 1.0 — this release adds CUR 2.0 support. If you're still on CUR 1.0 exports, now is the time to update your AWS billing export configuration and point OpenCost at the new format. Don't wait for AWS to force the migration.

• enhancementSuppress noisy Spot feed warnings with the new toggle

  Teams not using AWS Spot instances were getting misleading log warnings about spot data feeds. You can now explicitly disable the Spot Data Feed via config. Set the toggle if you're not using Spot — it cleans up your logs and removes the misleading provider log noise fixed in this release.

日本語 準備中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.

日本語 準備中v0.150.0 is a maintenance release with targeted bug fixes: corrects the print-config unredacted output, redacts internal telemetry OTLP headers in marshaled config, and fixes a bounds-check crash in the debug exporter.

• securityTelemetry exporter headers now redacted in marshaled config

  Internal telemetry OTLP exporter headers are now redacted when configuration is marshaled. If you log or store marshaled config output anywhere, headers (which may contain auth tokens) were previously exposed in plaintext. Upgrade and audit any stored config snapshots.

• enhancementFix print-config unredacted mode to show defaults

  The print-config command's unredacted mode previously dropped all default-valued options from output. Fixed by introducing confmap.WithUnredacted MarshalOption. If your team uses print-config for auditing or debugging configuration, re-run it after upgrading — the output is now complete and trustworthy.

日本語 準備中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.