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

# 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