CVE-2025-70042: Opensourcelabs Thermakube SSRF Vulnerability

CVE-2025-70042 Overview

CVE-2025-70042 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] affecting oslabs-beta ThermaKube, an open-source Kubernetes monitoring project maintained by OS Labs Beta. The flaw allows unauthenticated remote attackers to coerce the application into issuing HTTP requests to arbitrary destinations, including internal services that would normally be unreachable from the public network.

Exploitation requires no authentication or user interaction and can be performed over the network. Attackers can pivot through ThermaKube to reach cloud metadata endpoints, internal Kubernetes APIs, or other backend systems.

Critical Impact
Unauthenticated network attackers can force ThermaKube to make arbitrary outbound requests, exposing internal services, cloud metadata credentials, and Kubernetes control-plane endpoints.

Affected Products

opensourcelabs:thermakube (master branch)
ThermaKube deployments exposing the affected request handler
Kubernetes clusters monitored by vulnerable ThermaKube instances

Discovery Timeline

2026-03-09 - CVE-2025-70042 published to NVD
2026-03-18 - Last updated in NVD database

Technical Details for CVE-2025-70042

Vulnerability Analysis

The vulnerability resides in a ThermaKube server endpoint that accepts a URL or host parameter from a client request and dispatches an HTTP request to that destination without validating the target. Because the request originates from the ThermaKube server process, it inherits the network position and trust of the host, allowing access to resources unreachable from the public internet.

SSRF in a Kubernetes monitoring context is particularly impactful. ThermaKube typically runs inside or adjacent to a cluster with reachability to the Kubernetes API server, kubelet endpoints, and cloud provider instance metadata services such as 169.254.169.254. An attacker can read service account tokens, IAM credentials, or cluster configuration data through the coerced requests.

Root Cause

The root cause is missing allowlist validation and protocol restriction on user-supplied URLs passed into the server's HTTP client. The application does not block private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16) and does not constrain accepted schemes to https against approved hosts.

Attack Vector

The attacker sends a crafted HTTP request to the vulnerable ThermaKube endpoint containing a URL pointing to an internal target. ThermaKube fetches the URL and returns response data or side effects to the attacker. Technical details for the specific vulnerable handler are referenced in the ThermaKube GitHub Repository and the published GitHub Gist Resource.

No verified public proof-of-concept code is available at the time of publication. See referenced advisories for technical context.

Detection Methods for CVE-2025-70042

Indicators of Compromise

Outbound HTTP requests from ThermaKube pods to 169.254.169.254 or other link-local addresses
ThermaKube access logs containing URL parameters referencing private CIDR ranges or localhost
Unexpected requests from ThermaKube service accounts to the Kubernetes API server
DNS lookups from ThermaKube hosts for attacker-controlled domains used in blind SSRF probes

Detection Strategies

Inspect application logs for inbound parameters containing fully qualified URLs, IP literals, or non-standard schemes such as file:// and gopher://
Correlate ThermaKube egress traffic against an expected destination allowlist and alert on deviations
Monitor cloud audit logs for instance metadata service access patterns originating from monitoring workloads

Monitoring Recommendations

Enable Kubernetes NetworkPolicy logging to capture egress from ThermaKube pods
Forward web server and reverse proxy logs to a centralized analytics platform for query against SSRF payload patterns
Set alerts on access to cloud metadata endpoints from any workload that does not require it

How to Mitigate CVE-2025-70042

Immediate Actions Required

Remove ThermaKube from internet-exposed network segments until a fix is applied
Restrict egress from ThermaKube pods using Kubernetes NetworkPolicy to deny traffic to private ranges and metadata IPs
Rotate any cloud IAM credentials and Kubernetes service account tokens reachable from the ThermaKube host
Audit recent logs for evidence of SSRF probing or metadata access

Patch Information

At the time of publication, no official vendor patch is referenced in the NVD entry. Monitor the ThermaKube GitHub Repository for upstream commits addressing CWE-918 and the OS Labs Beta Repository organization for coordinated advisories.

Workarounds

Place ThermaKube behind an authenticating reverse proxy and reject requests containing URL parameters with IP literals or non-HTTPS schemes
Enforce IMDSv2 on AWS workloads to require session tokens for metadata access, blunting credential theft via SSRF
Apply egress firewall rules blocking ThermaKube traffic to 169.254.169.254, 127.0.0.0/8, and RFC1918 ranges except explicitly required destinations
Run ThermaKube with a least-privilege service account stripped of cluster-admin and cloud IAM permissions

bash

# Example NetworkPolicy restricting ThermaKube egress to DNS and approved targets
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: thermakube-egress-restrict
  namespace: monitoring
spec:
  podSelector:
    matchLabels:
      app: thermakube
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.0.0/16
        - 10.0.0.0/8
        - 172.16.0.0/12
        - 192.168.0.0/16
        - 127.0.0.0/8