Thanos just turned your Prometheus setup into something that can actually scale across data centers, and v0.42.0 makes it significantly more secure and flexible.
Imagine you run a chain of coffee shops. Each shop has its own cash register (Prometheus) that records every transaction. That works fine for one shop. But when you have fifty shops across five cities, you need a way to send all those receipts to a central vault, secure the connections between shops, and make sure one compromised register does not bring down the whole chain. Thanos is that central vault system for Prometheus metrics — it takes your local monitoring data and makes it globally queryable, durably stored, and infinitely scalable.
For Site Reliability Engineers and platform teams running distributed Prometheus setups, Thanos solves three painful problems: long-term storage (Prometheus alone loses old data), global querying (query all clusters at once instead of hopping between Prometheus instances), and high availability (no single point of failure for your monitoring). If you have ever stared at a Grafana dashboard showing only seven days of history while trying to debug a monthly anomaly, you already understand the pain.
Version v0.42.0 lands with a critical security fix for a CVSS 9.1 vulnerability, new per-endpoint TLS configuration for Query, TLS cipher and curve customization, Redis key prefix support, filesystem access confinement, and visible fanout information in the Query UI. There are also two breaking changes you need to know about before upgrading.
What Is New
Per-Endpoint TLS Configuration for Thanos Query
This is the headline feature. Previously, when Thanos Query connected to multiple downstream stores (sidecars, receivers, rulers), all connections shared a single TLS configuration. If Store A used a private CA and Store B used mTLS with a different certificate, you were stuck. Now each endpoint can have its own TLS settings, defined individually in the Query configuration.
This matters because real-world multi-cluster setups rarely have uniform PKI infrastructure. The team running the EU cluster might use Let’s Encrypt while the US cluster uses an internal corporate CA. With per-endpoint TLS, you point each store address at its own cert files and Thanos handles the rest.
thanos query \
--grpc-data-client=https://eu-store.example.com:10901 \
--grpc-data-client-server-tls-secure \
--grpc-data-client-server-ca-cert=eu-ca.crt \
--grpc-data-client=https://us-store.example.com:10901 \
--grpc-data-client-server-tls-secure \
--grpc-data-client-server-ca-cert=us-ca.crtTLS Cipher Suite and Curve Configuration
For teams with strict security compliance requirements (hello, FedRAMP and SOC2 auditors), Thanos now lets you explicitly configure which TLS cipher suites and elliptic curves your servers accept. Four new flags cover both the gRPC server and the Receive HTTP server:
- –grpc-server-tls-ciphers — restrict cipher suites for gRPC connections (PR #8730)
- –remote-write.server-tls-ciphers — restrict cipher suites for the HTTP remote-write server (PR #8730)
- –grpc-server-tls-curves — specify allowed elliptic curves for gRPC (PR #8770)
- –remote-write.server-tls-curves — specify allowed elliptic curves for HTTP (PR #8770)
No more scanner findings about deprecated cipher suites. Lock it down to exactly what your security policy mandates.
Redis Cache Key Prefix Support
If you share a Redis cluster between multiple Thanos instances (or between Thanos and other services), cache key collisions are a real headache. You can now set a key prefix so every cache entry from a specific Thanos instance is namespaced. This enables clean multi-tenant cache isolation without resorting to separate Redis deployments.
thanos query \
--query-range.response-cache-config="config:
type: REDIS
config:
addr: redis.example.com:6379
key_prefix: thanos-prod-eu"PR #8691 (also adds fanout info to the Query UI and improves compactor directory marker cleanup for S3-compatible stores)
Filesystem Access Confinement with os.Root
Receive, Compact, and Sidecar now use Go’s os.Root API to confine all filesystem access to the service’s data directory. This means a compromised or misconfigured Thanos component cannot read or write files outside its designated directory. It is the kind of defense-in-depth improvement that does not make headlines but makes your security team sleep better.
Fanout Information in Query UI
When you ask Thanos Query for a metric, it fans the request out to potentially dozens of stores, sidecars, and receivers. Until now, you had no visibility into which stores were queried and how long each took. The Query UI now shows fanout information, making it dramatically easier to debug slow queries and identify which store is the bottleneck in your topology.
TSDB Stats Endpoint
Ruler and Sidecar now expose TSDB statistics via gRPC, giving you programmatic access to head stats, series counts, and other internal metrics that were previously only available via the HTTP UI. This is particularly useful for building dashboards that track series churn or block compaction health.
Critical Security Fix
Thanos v0.42.0 patches CVE-2026-33186 (CVSS 9.1 — Critical), an authorization bypass via malformed :path headers. If you use Thanos’s grpc/authz interceptors with path-based “deny” rules, an attacker could craft requests with malformed path headers that slip past your deny rules entirely. The fix comes via a bump to the thanos-community/grpc-go fork.
Who is affected: any deployment using gRPC authorization interceptors with path-based deny rules. If you are not using grpc/authz, you are not directly affected — but you should still upgrade.
Advisory: GHSA-p77j-4mvh-x3m3 | PR #8726
Breaking Changes
- –shipper.ignore-unequal-block-size removed (PR #8670). TSDB now delays compaction until blocks have been uploaded by the shipper. This prevents data loss while allowing compaction during uploads. If you were passing this flag, remove it from your startup commands.
- –debug.advertise-compatibility-label removed (PR #8839). Stores no longer advertise the
@thanos_compatibility_store_type=storeexternal label by default. This breaks compatibility with Thanos Query versions before v0.8.0. If you are still running anything older than v0.8.0 (and honestly, you should not be), upgrade your Query instances first.
Notable Bug Fixes
- Exemplar proxy label stripping — external label matchers were being stripped in multi-tier Query topologies (Query A to Query B to Sidecar), causing incorrect routing. Now fixed. (PR #8752)
- OTLP tracing TLS fields ignored —
ca_file,cert_file, andkey_fileintls_configwere silently dropped when using the OTLP gRPC exporter. Deployments using private CAs or mTLS can now configure tracing TLS properly. (PR #8714) - Query-Frontend panic — an out-of-range access in
AnalyzesMergecaused panics when merging more than two query analyses. (PR #8701) - Receive 503 errors during restarts — intermittent 503s when restarting Receive components are fixed. (PR #8720)
- Tenant ID path traversal — tenant IDs extracted from split-tenant labels are now validated to prevent path traversal attacks. (PR #8806)
Other Improvements
- Redis replica reads — the Rueidis client now supports
SendToReplicas, letting read-only cache requests hit Redis replicas for better throughput. (PR #8802) - gRPC keepalive enforcement — all gRPC servers now set a
KeepaliveEnforcementPolicywithMinTime: 10s, matching the client interval. (PR #8799) - Query-Frontend log consistency — the
time_takenfield is nowtime_taken_msfor consistent JSON output. (PR #8830) - Compactor hashmod fix — dedup replica labels are now excluded from hashmod calculation, fixing a footgun that could cause unexpected compaction behavior. (PR #8853)
If you are running Thanos in production, upgrade this week — the CVE-2026-33186 fix alone justifies it, and the per-endpoint TLS configuration may eliminate a workaround you have been tolerating for years.
