CVE-2026-28416: gradio: SSRF allows internal network access

Q: Is CVE-2026-28416 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-28416, increasing the risk of exploitation.

Q: How to fix CVE-2026-28416?

1) Patch: upgrade to Gradio 6.6.0 immediately — this is the only full fix. 2) If patching is delayed: audit all gr.load() calls and whitelist only internal, verified Spaces; remove or gate any untrusted external Space loading. 3) Network controls: block outbound HTTP from Gradio servers to RFC1918 ranges and cloud metadata endpoints (169.254.169.254, metadata.google.internal, 169.254.169.254). 4) Least privilege: review and restrict IAM roles attached to instances hosting Gradio — ensure no overly permissive roles exist that SSRF-harvested credentials could abuse. 5) Detection: alert on outbound HTTP requests from Gradio processes to metadata ranges and internal subnets; review Gradio access logs for unexpected proxy_url patterns. 6) Incident response: if exposure is suspected, rotate all IAM credentials associated with affected Gradio hosts.

Q: What systems are affected by CVE-2026-28416?

This vulnerability affects the following AI/ML architecture patterns: ML prototyping environments, model serving, Hugging Face Spaces integrations, AI development workspaces, cloud-hosted ML infrastructure, model evaluation pipelines.

Q: What is the CVSS score for CVE-2026-28416?

CVE-2026-28416 has a CVSS v3.1 base score of 8.6 (HIGH). The EPSS exploitation probability is 7.26%.

GHSA-jmh7-g254-2cq9HIGHPoC AVAILABLECISA: TRACK*

Published February 27, 2026

CISO Take

Any Gradio deployment using `gr.load()` to load external or community Spaces is exposed to SSRF attacks that can reach cloud metadata endpoints (AWS IMDS, GCP metadata) and internal network services — a direct path to IAM credential theft and cloud account takeover. Patch to Gradio 6.6.0 immediately; if delay is unavoidable, restrict `gr.load()` to internal/trusted sources only and block egress to 169.254.169.254 at the network layer. Cloud-hosted ML environments are highest priority — this is not a theoretical risk.

What is the risk?

High operational risk. CVSS 8.6 with Changed scope means successful exploitation extends beyond Gradio to the underlying cloud infrastructure. Zero prerequisites — no authentication, no user interaction, low complexity — make this trivially weaponizable. The Hugging Face Spaces ecosystem creates a wide, self-service attack surface: any org that demos or evaluates community models via gr.load() is exposed. Cloud-deployed Gradio instances face the most severe outcome: IAM credential exfiltration enabling lateral movement into the full cloud account.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Gradio	pip	—	No patch
43.9KOpenSSF 5.9735 dependentsPushed 7d ago29% patched~108d to patchFull package profile →
Gradio	pip	< 6.6.0	`6.6.0`
43.9KOpenSSF 5.9735 dependentsPushed 7d ago29% patched~108d to patchFull package profile →

How severe is it?

CVSS 3.1

8.6 / 10

EPSS

7.3%

chance of exploitation in 30 days

Higher than 94% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SChanged

CHigh

INone

ANone

What should I do?

1 step

1) Patch: upgrade to Gradio 6.6.0 immediately — this is the only full fix. 2) If patching is delayed: audit all gr.load() calls and whitelist only internal, verified Spaces; remove or gate any untrusted external Space loading. 3) Network controls: block outbound HTTP from Gradio servers to RFC1918 ranges and cloud metadata endpoints (169.254.169.254, metadata.google.internal, 169.254.169.254). 4) Least privilege: review and restrict IAM roles attached to instances hosting Gradio — ensure no overly permissive roles exist that SSRF-harvested credentials could abuse. 5) Detection: alert on outbound HTTP requests from Gradio processes to metadata ranges and internal subnets; review Gradio access logs for unexpected proxy_url patterns. 6) Incident response: if exposure is suspected, rotate all IAM credentials associated with affected Gradio hosts.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data ExtractionCode ExecutionFrameworkModelTraining DataAML.T0006- Active Scanning AML.T0010.001- AI Software AML.T0011- User Execution AML.T0011.000- Unsafe AI Artifacts AML.T0025- Exfiltration via Cyber Means AML.T0049- Exploit Public-Facing Application AML.T0075- Cloud Service Discovery AML.T0078- Drive-by Compromise AML.T0106- Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurityArticle 9-Risk management system

ISO 42001

A.6.1.4-Information security in AI system lifecycleA.6.2.6-AI system access controlClause 8.4-AI System Operational Risk Management

NIST AI RMF

GOVERN 6.2-Policies and procedures are in place for AI supply chain risk managementMANAGE 2.4-Residual risks are managedMANAGE-2.2-Risk Treatment for AI System Vulnerabilities

OWASP LLM Top 10

LLM05-Supply Chain VulnerabilitiesLLM07-Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-28416?

Is CVE-2026-28416 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-28416, increasing the risk of exploitation.

How to fix CVE-2026-28416?

1) Patch: upgrade to Gradio 6.6.0 immediately — this is the only full fix. 2) If patching is delayed: audit all gr.load() calls and whitelist only internal, verified Spaces; remove or gate any untrusted external Space loading. 3) Network controls: block outbound HTTP from Gradio servers to RFC1918 ranges and cloud metadata endpoints (169.254.169.254, metadata.google.internal, 169.254.169.254). 4) Least privilege: review and restrict IAM roles attached to instances hosting Gradio — ensure no overly permissive roles exist that SSRF-harvested credentials could abuse. 5) Detection: alert on outbound HTTP requests from Gradio processes to metadata ranges and internal subnets; review Gradio access logs for unexpected proxy_url patterns. 6) Incident response: if exposure is suspected, rotate all IAM credentials associated with affected Gradio hosts.

What systems are affected by CVE-2026-28416?

This vulnerability affects the following AI/ML architecture patterns: ML prototyping environments, model serving, Hugging Face Spaces integrations, AI development workspaces, cloud-hosted ML infrastructure, model evaluation pipelines.

What is the CVSS score for CVE-2026-28416?

CVE-2026-28416 has a CVSS v3.1 base score of 8.6 (HIGH). The EPSS exploitation probability is 7.26%.

What is the AI security impact?

Affected AI Architectures

ML prototyping environmentsmodel servingHugging Face Spaces integrationsAI development workspacescloud-hosted ML infrastructuremodel evaluation pipelines

MITRE ATLAS Techniques

AML.T0006Active Scanning

AML.T0010.001AI Software

AML.T0011User Execution

AML.T0011.000Unsafe AI Artifacts

AML.T0025Exfiltration via Cyber Means

AML.T0049Exploit Public-Facing Application

AML.T0075Cloud Service Discovery

AML.T0078Drive-by Compromise

AML.T0106Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15, Article 9

ISO 42001: A.6.1.4, A.6.2.6, Clause 8.4

NIST AI RMF: GOVERN 6.2, MANAGE 2.4, MANAGE-2.2

OWASP LLM Top 10: LLM05, LLM07

What are the technical details?

Original Advisory

Gradio is an open-source Python package designed for quick prototyping. Prior to version 6.6.0, a Server-Side Request Forgery (SSRF) vulnerability in Gradio allows an attacker to make arbitrary HTTP requests from a victim's server by hosting a malicious Gradio Space. When a victim application uses `gr.load()` to load an attacker-controlled Space, the malicious `proxy_url` from the config is trusted and added to the allowlist, enabling the attacker to access internal services, cloud metadata endpoints, and private networks through the victim's infrastructure. Version 6.6.0 fixes the issue.

Exploitation Scenario

An attacker publishes a malicious Gradio Space on Hugging Face with a config embedding `proxy_url: http://169.254.169.254/latest/meta-data/iam/security-credentials/prod-ml-role`. A security engineer at a target org runs `gr.load('attacker/demo-model')` to evaluate the Space during routine model vetting. Gradio trusts the returned proxy_url and adds it to the allowlist. The attacker then proxies requests through the victim's server to the metadata endpoint, harvesting temporary AWS IAM credentials for the `prod-ml-role` attached to the Gradio host. With those credentials, the attacker pivots to S3 buckets containing proprietary training data, model artifacts, and customer datasets — achieving data exfiltration with no direct access to victim infrastructure.

Weaknesses (CWE)

CWE-918Server-Side Request ForgeryPrimary CWE-918Server-Side Request Forgery (SSRF)Primary

CWE-918 — Server-Side Request Forgery: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.