CVE-2026-28416

What it actually does

CVE-2026-28416 is a server-side request forgery vulnerability in Gradio versions prior to 6.6.0. When an application calls `gr.load()` to load a Gradio Space controlled by an attacker, Gradio can trust a malicious `proxy_url` value from that Space’s configuration and add it to an allowlist. This lets the attacker cause the victim server to initiate arbitrary HTTP requests from its own network context. The most serious technical impact is unauthorized access to resources reachable from the server but not from the public internet, including internal HTTP services, private network addresses, and cloud instance metadata endpoints. The CVSS vector indicates network exploitable, low-complexity exploitation with no privileges or user interaction required, with high confidentiality impact and limited integrity impact.

Why it matters to the business

Organizations using vulnerable Gradio versions to dynamically load external or untrusted Spaces may expose internal services and cloud metadata through their application infrastructure. Successful exploitation can lead to theft of secrets, cloud credentials, service tokens, internal API data, or environment-specific configuration, which may enable follow-on compromise. The risk is highest for internet-facing Gradio deployments, applications that call `gr.load()` with third-party Spaces, and deployments running in cloud environments where metadata services or internal control-plane APIs are reachable. Although this vulnerability is not currently listed in CISA KEV and exploit maturity is reported as none, the issue has a high CVSS score and an EPSS score indicating non-trivial exploitation probability, so remediation should be prioritized for exposed or cloud-hosted systems.

How an attack unfolds

An attacker creates or controls a malicious Gradio Space and publishes configuration containing a crafted `proxy_url`. A victim application using a vulnerable Gradio release loads that Space with `gr.load()`. Because vulnerable Gradio versions trust the Space-provided `proxy_url`, the victim application adds the attacker-controlled proxy target to its allowlist. The attacker then uses the loaded Space behavior to make the victim server issue HTTP requests to attacker-selected destinations. Those destinations may include internal web services, loopback interfaces, RFC1918 private network ranges, Kubernetes or container control endpoints, or cloud metadata addresses such as link-local metadata services. Responses may disclose sensitive data such as metadata credentials, internal API responses, tokens, or service configuration, giving the attacker intelligence or credentials for later lateral movement or cloud account abuse.

How to fix it

Upgrade Gradio to version 6.6.0 or later wherever Gradio is used. If immediate upgrade is not possible, avoid loading untrusted or third-party Spaces with `gr.load()`, restrict which Spaces can be loaded, and treat remote Space configuration as untrusted input. Add egress controls that prevent application servers from reaching sensitive internal ranges and metadata endpoints unless explicitly required. Block access from Gradio application processes to loopback-only administration ports, RFC1918 address ranges not needed for operation, link-local metadata addresses such as `169.254.169.254`, IPv6 metadata/link-local destinations, and internal DNS names. In cloud environments, enforce metadata service protections such as IMDSv2 where applicable, restrict instance roles to least privilege, and rotate credentials if metadata access is suspected. Review application code and deployment patterns for dynamic `gr.load()` usage and remove or constrain any functionality that allows attacker-influenced Space selection.

How to confirm the fix worked

Confirm all installed Gradio packages report version 6.6.0 or later using package inventory, dependency lockfiles, container manifests, and runtime checks such as `python -c "import gradio; print(gradio.__version__)"`. Search application code for `gr.load(` and verify that any loaded Spaces are trusted and fixed, not user-controllable. Test network egress from the Gradio runtime to ensure requests to metadata endpoints, loopback services, and private network ranges are blocked unless explicitly required. Review dependency scanners and software composition analysis results to ensure no vulnerable Gradio version remains in virtual environments, notebooks, containers, CI images, or transitive application bundles. Where practical, run a controlled SSRF validation using a benign internal canary endpoint and verify that untrusted Space configuration cannot cause the server to request arbitrary URLs.

Typical attack path

1. Identify an application using Gradio versions prior to 6.6.0 that loads external Spaces through `gr.load()`.
2. Create or control a malicious Gradio Space with a crafted configuration containing an attacker-selected `proxy_url`.
3. Induce or rely on the victim application to load the malicious Space.
4. Abuse the trusted `proxy_url` handling so the malicious proxy target is added to the victim server’s allowlist.
5. Send requests that cause the victim server to connect to internal or otherwise unreachable endpoints.
6. Probe private network ranges, loopback services, service discovery endpoints, container orchestration APIs, or cloud metadata services.
7. Collect HTTP responses containing internal data, credentials, tokens, or configuration details.
8. Use any obtained secrets or network intelligence for follow-on access, lateral movement, or cloud resource compromise.

How to detect it

To assess whether exploitation already occurred, review application logs, reverse proxy logs, egress firewall logs, DNS logs, cloud VPC flow logs, container network telemetry, and EDR process network events for outbound HTTP requests originating from Gradio-hosting processes or hosts to internal and metadata destinations. Focus on the period after any application loaded an external Space, especially unfamiliar Hugging Face Space names or dynamically supplied Space identifiers. Look for requests to link-local cloud metadata addresses, loopback addresses, RFC1918 private ranges, Kubernetes service IPs, Docker or container API endpoints, internal admin panels, and unexpected `proxy_url` values in Gradio configuration retrieval or debug logs. Investigate Python processes running Gradio that made outbound connections to destinations unrelated to normal application behavior. If suspicious access to metadata endpoints is observed, examine cloud audit logs for subsequent use of temporary credentials, unusual API calls, new access keys, privilege enumeration, or lateral movement. There are no known public exploit-specific payload strings in the supplied information, so detection should emphasize behavioral indicators of SSRF and unauthorized egress from Gradio workloads.

• gr.load(
• proxy_url
• 169.254.169.254
• http://169.254.169.254
• http://169.254.169.254/latest/meta-data/
• http://169.254.169.254/latest/api/token
• metadata.google.internal
• http://metadata.google.internal/computeMetadata/v1/
• 169.254.169.254/metadata/instance
• http://169.254.169.254/metadata/identity/oauth2/token
• 100.100.100.200
• http://100.100.100.200/latest/meta-data/
• 127.0.0.1
• http://127.0.0.1
• localhost
• http://localhost
• 0.0.0.0
• 10.
• 172.16.
• 172.17.
• 172.18.
• 172.19.
• 172.20.
• 172.21.
• 172.22.
• 172.23.
• 172.24.
• 172.25.
• 172.26.
• 172.27.
• 172.28.
• 172.29.
• 172.30.
• 172.31.
• 192.168.
• /var/run/docker.sock
• kubernetes.default.svc
• KUBERNETES_SERVICE_HOST

What your security team should do

• Prioritize upgrading all Gradio installations to version 6.6.0 or later, especially internet-facing and cloud-hosted deployments.
• Inventory applications, notebooks, containers, and ML demo services using Gradio and identify any use of `gr.load()` with external or user-influenced Spaces.
• Temporarily disable or restrict loading of untrusted third-party Spaces until patching and validation are complete.
• Implement outbound network controls for Gradio runtimes to deny access to cloud metadata endpoints, loopback addresses, private address ranges, and internal administrative services by default.
• Review cloud instance roles, service account permissions, and secrets accessible from Gradio-hosting infrastructure; rotate credentials if suspicious metadata or internal-service access is found.
• Add monitoring for unusual outbound HTTP requests from Gradio processes to internal IP ranges, link-local addresses, or unexpected domains.
• Harden cloud metadata access, such as requiring IMDSv2 where supported and applying least-privilege role permissions.
• Include Gradio dependency checks in CI/CD and container image scanning to prevent reintroduction of versions earlier than 6.6.0.