We ship security fixes in the latest release of Gradio and its first-party clients. Please reproduce on the current released version before reporting — we do not backport fixes to older releases.

Report privately — do not open a public issue or PR for a suspected vulnerability.

• Preferred: GitHub private vulnerability reporting — use the Report a vulnerability button under this repository's Security tab. This routes the report to the maintainers, keeps it private until a fix is ready, and lets us issue a CVE through GitHub if warranted.
• Email: security@huggingface.co, and cc gradio-team@huggingface.co.

We acknowledge valid, in-scope reports and will keep you updated on remediation. Please give us a reasonable window to fix the issue before any public disclosure.

We do not offer a monetary bounty. For a valid, in-scope report, we credit you on the published GitHub Security Advisory and name you as the reporter in the associated CVE. Let us know how you would like to be credited (name or handle).

We receive a high volume of reports. To be triaged, a report must follow the structure below. Copy this block into your submission and fill in every field. Reports missing the version, proof of concept, or impact are returned as incomplete and are not investigated until provided.

### Summary
One sentence: what the vulnerability is and where.

### Affected version / commit
Exact released version or commit SHA you reproduced on (for example,
`gradio==X.Y.Z` / `a1b2c3d`). Not "latest" or "main".

### Affected component
The public API, module, component, route, or client entry point involved (for
example, `gr.Blocks.launch`, `gr.File`, or `gradio_client.Client.predict`).

### Vulnerability class
Type and CWE if known (for example, path traversal / CWE-22 or cross-site
scripting / CWE-79).

### Attack vector & preconditions
- How is the vulnerable code reached? Which API call, component, route, input,
  or configuration is involved?
- Who is the attacker, and what do they control?
- What must be true for the attack to work? Consider authentication, network
  exposure, user interaction, non-default settings, custom code, and malicious
  files or remote apps.

### Proof of concept
A minimal, self-contained app, client script, or step sequence that runs on a
clean install of the version above. Include:
- the exact commands and code to run,
- any input files needed (attach them or provide a script that generates them),
- the expected behavior and the actual behavior you observed.
A snippet showing that a function exists or could be misused is not a PoC.

### Impact
What an attacker gains in a realistic deployment. "Could theoretically..."
without a working chain is not an impact.

### Scope
Which trust boundary below does this cross? If your finding touches anything in
the "Out of scope" list, name the item and explain why the behavior nonetheless
violates a guarantee Gradio makes.

### Suggested severity (optional)
We assign the final severity. Include a CVSS v3.1 vector only if you have one.

### Suggested fix (optional)

The bar is a reproducible PoC against a supported version, with a concrete impact that crosses a trust boundary we actually defend. Reports that are theoretical, auto-generated by a scanner or LLM, or that restate documented behavior will be closed without detailed review.

Understanding these boundaries saves everyone time — most reports we close as not vulnerabilities fall inside one of them.

Application code is trusted. A Gradio app runs Python callbacks supplied by the app author. It may also deliberately include JavaScript, CSS, HTML, custom components, authentication functions, and other application-controlled logic. Gradio does not sandbox this code. A callback reading local files, making network requests, running commands, or returning sensitive information is application behavior, not a vulnerability in Gradio. A Gradio protection being bypassed by untrusted input is in scope.

Exposing an app is a deployment decision. A share link, a server bound to a public interface, or a publicly reachable API allows other people to interact with the app and invoke the functionality its author exposed. Gradio does not turn an unsafe callback into a safe multi-user service. Authentication or access controls supplied by Gradio must still behave as documented; a demonstrated bypass is in scope.

File access configured by the app author is intentional. Files explicitly returned by an app or exposed through settings such as allowed_paths are trusted by that author for serving. Likewise, a directory in allowed_paths may expose every file beneath it. Reading or writing a file outside the paths and outputs the app authorized, or bypassing blocked_paths, is in scope.

Custom frontend content is trusted. App-provided scripts, HTML, CSS, and custom components can execute in the app's page and are not a sandbox boundary. However, untrusted end-user input rendered by standard Gradio components must not cross browser or session boundaries contrary to Gradio's documented behavior.

Remote apps are separate trust domains. When using gr.load, gradio_client, or @gradio/client, treat the remote app and the content it returns as untrusted. Incorrect or malicious output produced by that app is not a Gradio vulnerability. A remote app response that causes the client library to execute code, escape an intended download directory, or disclose unrelated local data without an explicit application decision is in scope.

We treat as vulnerabilities issues in the published Gradio package or first-party client code that an attacker can trigger without the app author or user opting into a documented risk. Examples include:

• code execution, path traversal, unauthorized file access, or server-side request forgery reachable through normal Gradio APIs or standard components;
• cross-site scripting or cross-user browser access caused by untrusted input in standard components;
• bypasses of Gradio authentication, session isolation, file-access controls, or other protections we document;
• exposure or mishandling of credentials, tokens, uploaded files, or another user's data by Gradio;
• client-side code execution, unintended local file writes, or local data disclosure caused by a malicious remote app response;
• remotely triggerable denial of service with concrete impact on a realistic shared or multi-tenant deployment; and
• CI/CD or supply-chain issues in this repository.

The following are not treated as vulnerabilities in Gradio. If your finding touches one of these, the report must explain why it nonetheless violates a guarantee Gradio makes; otherwise, it will be closed.

• Unsafe or malicious behavior implemented by an app's own Python callbacks, authentication function, JavaScript, CSS, HTML, or custom components.
• Access to functionality intentionally exposed by an unauthenticated public app, share link, or API, absent a bypass of a Gradio security control.
• Access to files the app explicitly returns or exposes through configuration such as allowed_paths.
• Incorrect, unsafe, or malicious model output, including jailbreaks, prompt injection, harmful generations, and behavior controlled by a remote app or model rather than Gradio.
• Findings in demo/, examples/, documentation, tests, or other non-packaged reference material.
• Local denial of service from pathological input on your own machine, absent a shared, multi-tenant, or remotely reachable impact.
• Vulnerabilities in third-party dependencies we do not vendor. Report these upstream; we will upgrade once a fix is available.
• Theoretical issues without a working proof of concept, and reports generated by scanners or LLMs without a verified, reproducible chain.
• Best-practice or hardening suggestions without demonstrated impact, including missing email-authentication records, missing HTTP security headers, TLS preferences, and similar scanner or configuration-checker output.
• Issues that reproduce only on an unsupported older release and do not reproduce on the current release.

Good-faith research that respects these guidelines, avoids privacy violations and service disruption, and gives us a reasonable disclosure window will not be pursued by us. Do not access data that is not yours, and do not run tests against Hugging Face production infrastructure.