CVE-2026-79760: Termix SSRF Vulnerability

CVE-2026-79760 Overview

CVE-2026-79760 is a Server-Side Request Forgery (SSRF) vulnerability in Termix, a web-based server management platform that provides SSH terminal, tunneling, and file editing capabilities. The flaw affects versions 2.5.0 through 2.5.1 and allows authenticated users to abuse the notification-channel test endpoint. Attackers configure webhook or ntfy notification channels pointing to internal destinations, then trigger the Termix server to issue blind HTTP requests to private network services. The webhook mode additionally permits attacker-controlled HTTP methods and headers, enabling limited state changes against internal services that accept the fixed notification body.

Critical Impact
Authenticated attackers can pivot through the Termix server to reach internal HTTP services, perform network reconnaissance, and trigger limited state-changing requests against private-network APIs.

Affected Products

Termix 2.5.0
Termix versions prior to 2.5.1
Self-hosted Termix server management deployments

Discovery Timeline

2026-09-24 - CVE-2026-79760 published to the National Vulnerability Database (NVD)
2026-09-28 - Last updated in NVD database
Fixed in Termix 2.5.1 - See GitHub Release v2.5.1 and GitHub Security Advisory GHSA-6hx3-9mgq-h9fj

Technical Details for CVE-2026-79760

Vulnerability Analysis

The vulnerability is a Server-Side Request Forgery flaw classified under [CWE-918]. The request path in src/backend/database/routes/alert-rules-routes.ts passes attacker-supplied destinations to src/backend/utils/notification-sender.ts without validating the target URL. No allowlist is applied, and private IP ranges are not blocked.

An authenticated user can configure a webhook or ntfy notification channel with any URL, including http://127.0.0.1, http://169.254.169.254/ cloud metadata endpoints, or arbitrary RFC 1918 addresses. Triggering the notification-channel test endpoint causes the Termix backend to send an HTTP request to that destination. Response bodies are not returned to the attacker, making the SSRF blind.

In webhook mode, the attacker also controls the HTTP method and request headers. This expands impact beyond reconnaissance: internal services that accept the fixed notification body may perform state changes such as creating resources, invalidating caches, or triggering actions.

Root Cause

The notification sender performs outbound HTTP requests using user-controlled URLs without destination filtering. The pre-patch code lacks any DNS resolution check, IP block enforcement, or scheme validation before invoking the HTTP client.

Attack Vector

Exploitation requires network access to the Termix web interface and valid authenticated credentials with permission to configure notification channels. The attacker creates a notification channel, points it at an internal URL, and uses the test endpoint to coerce the server into issuing the request.

typescript

// Patch: src/backend/utils/notification-sender.ts introduces safeOutboundFetch
 import { statsLogger } from "./logger.js";
+import { safeOutboundFetch } from "./safe-outbound-fetch.js";
 
 export interface AlertPayload {
   hostName: string;

typescript

// Patch: new src/backend/utils/safe-outbound-fetch.ts enforces an IP BlockList
+import { lookup } from "dns";
+import { BlockList, isIP } from "net";
+import { Agent } from "undici";
+
+const blockedAddresses = new BlockList();
+
+for (const [network, prefix] of [
+  ["0.0.0.0", 8],
+  ["10.0.0.0", 8],
+  ["100.64.0.0", 10],
+  ["127.0.0.0", 8],
+  ["169.254.0.0", 16],
+  ["172.16.0.0", 12],
+  ["192.168.0.0", 16],
+  ["198.18.0.0", 15],
+  ["224.0.0.0", 4],
+  ["240.0.0.0", 4],
+] as const) {
+  blockedAddresses.addSubnet(network, prefix, "ipv4");
+}

Source: GitHub Commit e1d1a3e

Detection Methods for CVE-2026-79760

Indicators of Compromise

Notification channel configurations in Termix referencing loopback addresses, RFC 1918 ranges, link-local 169.254.0.0/16, or cloud metadata endpoints
Outbound HTTP requests originating from the Termix backend process to internal-only hosts that do not match normal webhook destinations
Repeated calls to the notification-channel test endpoint from a single authenticated session

Detection Strategies

Review Termix application and audit logs for creation or modification of alert rules and notification channels, correlating with the user identity and destination URL
Monitor egress proxy and firewall logs for connections from the Termix host to private address ranges that were previously unused
Alert on HTTP requests from the Termix server using non-standard methods (PUT, DELETE, PATCH) in webhook payload tests

Monitoring Recommendations

Enable verbose logging on the Termix backend to capture every outbound notification request including destination, method, and headers
Deploy network segmentation telemetry around the Termix host to flag lateral HTTP traffic
Baseline normal notification destinations and alert on deviations

How to Mitigate CVE-2026-79760

Immediate Actions Required

Upgrade Termix to version 2.5.1 or later, which introduces the safeOutboundFetch wrapper and private-address BlockList
Audit all existing notification channels and remove any pointing to internal, loopback, or metadata addresses
Restrict Termix user accounts with notification-configuration privileges to trusted administrators

Patch Information

The fix is included in Termix 2.5.1. The relevant commits are ddbdd5c and e1d1a3e, merged through Pull Request #1067. Full advisory details are available in GHSA-6hx3-9mgq-h9fj.

Workarounds

Place the Termix server behind an egress proxy that denies connections to RFC 1918, loopback, and link-local address ranges
Run Termix in a network segment with no routable path to sensitive internal HTTP services or cloud metadata endpoints
Temporarily disable webhook and ntfy notification channels until the upgrade is applied

bash

# Example egress firewall rules to block SSRF targets from the Termix host
iptables -A OUTPUT -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -d 169.254.0.0/16 -j REJECT