Skip to main content
CVE-2025-48431VulnerabilityPublished Updated

Red Hat Security Advisory: Red Hat OpenShift distributed tracing platform (Tempo) 3.10.0 release

Affects Red HatSource GCVE Database

0
Compare
Authoritative record:CVE-2025-48431· High 7.5

Not known to be exploited · CVSS 7.5 High : upgrade Red Hat to 0.23.0 soon.

Data as of 29 Oct 2026, 09:14 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
1.0% chance of exploitation in 30 days – higher than 63% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 0.23.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 28 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Upgrade Apache Thrift to 0.23.0.

Affected software

ProductAffectedFixed in
Apache Software FoundationApache ThriftAffected
  • <0.23.0
Fixed in
  • 0.23.0

Description

This release of the Red Hat OpenShift distributed tracing platform (Tempo) provides new features, security improvements, and bug fixes. Breaking changes: * None. Deprecations: * None. Technology Preview features: * None. Enhancements: * TempoStack support for the automatically injected CA bundle: The TempoStack custom resource supports the automatically injected CA bundle ca-bundle.crt for storage TLS configuration. This CA bundle is supported in addition to the service-ca.crt and ca.crt certificates. As a result, you can use the automatically injected CA bundle to simplify TLS configuration for storage for your TempoStack instances. For more information, see https://redhat.atlassian.net/browse/TRACING-6222. * Cluster TLS profile adherence: This update introduces support for cluster TLS profile adherence. The Operator uses the TLS configuration from the APIServer custom resource in all TLS communication in the Operator and its operands. As a result, you can configure the TLS cluster profile by using environment variables. For more information, see https://redhat.atlassian.net/browse/TRACING-5845. * Optional spec.size field provides predefined resource configurations: The TempoStack custom resource supports the optional spec.size field, which provides predefined, pre-tested resource configurations. The following sizes are available: 1x.demo, 1x.pico, 1x.extra-small, 1x.small, and 1x.medium. The selected size sets the resource requests and limits for the TempoStack components and a default replication factor if one is not explicitly specified. The default replication factor is 1 for 1x.demo and 2 for the other sizes. As a result, you can deploy a TempoStack instance without manually calculating resources for each component. For more information, see https://redhat.atlassian.net/browse/TRACING-5376. * Custom environment variables for TempoStack containers: The TempoStack custom resource supports the spec.env and spec.envFrom fields, which allow you to inject custom environment variables into all Tempo containers, including values sourced from a secret or config map. Combined with the spec.extraConfig field, you can reference these environment variables in the Tempo configuration by using the ${VAR_NAME} syntax. As a result, you can supply the password for a password-protected Redis cache from a secret instead of embedding it in the custom resource. For more information, see https://redhat.atlassian.net/browse/TRACING-5933. Bug fixes: * The tempo-gateway-opa container starts in namespaces that enforce a LimitRange: Before this update, the tempo-gateway-opa container was created without default resource requests and limits when percentage-based resource calculation was used. As a consequence, the container could fail to start in namespaces that enforce a LimitRange resource. With this update, the Operator sets default resource requests and limits on the tempo-gateway-opa container. As a result, the tempo-gateway-opa container starts as expected. For more information, see https://redhat.atlassian.net/browse/TRACING-5716. * TempoStack and TempoMonolithic resources no longer get stuck in a terminating state: Previously, the certificate rotation controllers in the Tempo Operator updated certificate hash annotations without checking whether a resource had a deletion timestamp. When a TempoStack or TempoMonolithic resource was deleted, these annotation updates caused resource version conflicts that prevented the foreground deletion finalizer from being removed. As a result, resources remained stuck in a terminating state. With this update, the certificate rotation controllers skip annotation updates when a resource is being deleted. As a result, TempoStack and TempoMonolithic resources are deleted correctly without getting stuck in a terminating state. For more information, see https://redhat.atlassian.net/browse/TRACING-6138. * TempoStack gateway pods spread across nodes for high availability: Previously, the TempoStack gateway deployment did not set a pod anti-affinity rule. Other components such as the distributor, querier, query front end, and ingesters did set a pod anti-affinity rule. As a result, all gateway replicas could be scheduled on the same node, reducing high availability. With this update, the gateway and compactor deployments set pod anti-affinity rules. As a result, gateway replicas are spread across nodes, which can improve high availability. For more information, see https://redhat.atlassian.net/browse/TRACING-6148. * The gateway correctly forwards OTLP HTTP traffic over HTTPS for Tempo Monolithic: Before this update, when Tempo Monolithic was configured with 'multitenancy.enabled: true' and 'ingestion.otlp.http.tls.enabled: true', the gateway forwarded OTLP HTTP traffic to the Tempo receiver using plain HTTP instead of HTTPS. As a consequence, the connection failed with a 'connection reset by peer' error because the receiver expected TLS connections. With this update, the gate

References

Community reviews

Loading reviews…