CVE-2026-42344: FastGPT DNS Rebinding Vulnerability

CVE-2026-42344 Overview

FastGPT is an open-source AI Agent building platform developed by labring. CVE-2026-42344 affects FastGPT versions 4.14.11 and earlier. The vulnerability resides in the isInternalAddress() function within packages/service/common/system/utils.ts. The function attempts to block Server-Side Request Forgery (SSRF) by resolving the hostname using dns.resolve4() and dns.resolve6(), then checking whether resolved IPs fall within private ranges. Because the subsequent HTTP request triggers a fresh DNS resolution, an attacker can change the DNS response between the validation check and the fetch. This Time-of-Check to Time-of-Use (TOCTOU) flaw enables DNS rebinding attacks against internal infrastructure.

Critical Impact
Attackers can bypass SSRF protections and reach internal network services, cloud metadata endpoints, and other resources reachable from the FastGPT server.

Affected Products

FastGPT versions 4.14.11 and prior
labring/FastGPT AI Agent building platform
Deployments exposing FastGPT URL-fetching features to untrusted users

Discovery Timeline

2026-05-08 - CVE-2026-42344 published to NVD
2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-42344

Vulnerability Analysis

The vulnerability is a classic TOCTOU race condition mapped to [CWE-367]. FastGPT validates URLs by resolving the target hostname and comparing the returned IP addresses against private and loopback address ranges. If the addresses appear public, the application proceeds to fetch the URL. The validation and the fetch perform independent DNS lookups, so the answer can change between them.

An attacker controls an authoritative DNS server for a domain. The server returns a public IP address on the first query, satisfying the isInternalAddress() check. On the second query, made by the HTTP client during the fetch, the server returns an internal IP such as 127.0.0.1, 169.254.169.254, or an RFC1918 address. The fetch then targets internal services while bypassing the SSRF allowlist.

Root Cause

The root cause is the separation between DNS resolution used for validation and DNS resolution used for the outbound request. isInternalAddress() calls dns.resolve4() and dns.resolve6() directly, then returns control to the caller. The HTTP client later issues its own DNS query through the operating system resolver. Because no IP is pinned, no cache is shared, and TTL values can be set to zero by the attacker, the two lookups can return different records.

Attack Vector

An authenticated low-privilege user submits a URL pointing to an attacker-controlled domain. The attacker's DNS server alternates responses between a benign public IP and an internal target. FastGPT validates against the public IP, then fetches against the internal IP. Reachable targets include cloud metadata services, internal admin APIs, and other services bound to localhost or the private network. See the GitHub Security Advisory GHSA-cc8x-jrqv-hmwh for full technical details.

Detection Methods for CVE-2026-42344

Indicators of Compromise

Outbound HTTP requests from FastGPT server processes to RFC1918 ranges, 127.0.0.0/8, or 169.254.169.254
DNS queries from FastGPT hosts returning low-TTL (0–5 second) responses for external domains
Repeated DNS lookups for the same hostname within seconds, returning differing IP families
Unexpected access logs on internal services originating from the FastGPT application server

Detection Strategies

Inspect application logs for URL-fetch features invoked with hostnames resolving to short TTLs
Correlate DNS resolver telemetry with outbound HTTP connections to identify rebinding patterns
Alert on FastGPT egress traffic destined for cloud metadata IPs or private CIDR blocks
Review HTTP client libraries used by FastGPT for DNS pinning behavior

Monitoring Recommendations

Forward DNS query logs and FastGPT egress flow logs to a central analytics platform
Track answer-IP changes per hostname within a sliding 30-second window
Monitor for access attempts to 169.254.169.254, metadata.google.internal, and similar metadata endpoints
Audit user-submitted URLs and the resolved IPs at request time

How to Mitigate CVE-2026-42344

Immediate Actions Required

Restrict the FastGPT URL-fetching functionality to trusted users until a patch is available
Deploy an egress proxy that enforces destination allowlists for outbound HTTP traffic from FastGPT
Block FastGPT server access to cloud metadata IPs and private CIDR ranges at the network layer
Configure DNS resolvers to enforce a minimum TTL, reducing the rebinding window

Patch Information

At time of publication, no official patch is available from the labring/FastGPT project. Monitor the GitHub Security Advisory GHSA-cc8x-jrqv-hmwh for release updates. A correct fix pins the resolved IP from the validation step and uses that IP for the actual HTTP connection, removing the second DNS lookup.

Workarounds

Place FastGPT behind an outbound HTTP proxy that resolves hostnames once and enforces IP-based egress rules
Run FastGPT in a network segment with no route to internal services or cloud metadata endpoints
Use a custom HTTP agent that resolves the hostname, validates the IP, and connects directly to that IP
Disable user-supplied URL ingestion features until the upstream fix lands

bash

# Example iptables rules to block FastGPT egress to internal targets
iptables -A OUTPUT -m owner --uid-owner fastgpt -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner fastgpt -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner fastgpt -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner fastgpt -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner fastgpt -d 127.0.0.0/8 -j REJECT