CVE-2025-48889

What it actually does

The flaw is an improper input validation issue in Gradio's flagging feature. An unauthenticated remote user can cause the application server to copy a file that is readable by the Gradio process from the local filesystem into the application's flagging output/storage area. The attacker is not expected to directly receive the copied file contents through the vulnerable action, so the primary impact is availability: copying very large files, special device files, or endless streams such as /dev/urandom can rapidly consume disk space. There is also secondary data-handling risk if sensitive files are copied into locations later exposed to administrators, logs, backups, model artifacts, or other application workflows.

Why it matters to the business

Successful exploitation can make Gradio-based applications unavailable by filling disks, causing failed uploads, failed model inference, application crashes, logging failures, container eviction, or broader service instability on shared hosts. Although the EPSS score is low and it is not listed in CISA KEV or ransomware-tracked exploitation, the issue has been public for a long period, so internet-exposed Gradio services should be treated as patch candidates. Organizations running affected Gradio code in demos, AI labs, notebook services, or production ML interfaces may experience outages even from unsophisticated abuse because exploitation does not require authentication.

How an attack unfolds

An attacker first identifies a reachable Gradio application with the flagging feature enabled. They then submit crafted flagging input that references a local filesystem path instead of an expected user-controlled artifact. Because the server does not sufficiently validate the path before performing the copy, the Gradio process attempts to copy that server-side file into the flagging storage location. For denial of service, the attacker chooses a large file or an endless/special source such as /dev/urandom or /dev/zero, causing the copy operation to consume disk space until the filesystem is full or the process fails. Once storage is exhausted, the Gradio application and potentially other services using the same filesystem may become unstable or unavailable.

How to fix it

Upgrade Gradio to a version that includes the upstream fix, or ensure the deployed source includes gradio-app/gradio commit 16c9b246f714c03a2ece8f96515f55636700dc27 or later. If package-managed dependencies are in scope for affected Ubuntu libxslt packages listed by the advisory feed, update to the fixed OS packages: Ubuntu 14.04 LTS libxslt 1.1.28-2ubuntu0.2, Ubuntu 16.04 LTS libxslt 1.1.28-2.1ubuntu0.2, and Ubuntu 18.04 LTS libxslt 1.1.29-5ubuntu0.1. As immediate mitigation, disable Gradio flagging where not required, require authentication before access to the Gradio interface, restrict exposure to trusted networks, and run the service with least-privilege filesystem permissions. Place flagging/output directories on filesystems with strict quotas, monitor free space, avoid sharing critical host filesystems with Gradio containers, and consider read-only container filesystems with explicitly writable temporary/output mounts.

How to confirm the fix worked

Confirm the deployed Gradio version or source commit includes the fix at or after 16c9b246f714c03a2ece8f96515f55636700dc27. Review configuration to verify whether flagging is disabled or restricted when not needed. In a controlled non-production environment, attempt a benign validation using a known local path such as /etc/hostname or a temporary test file and verify the flagging workflow rejects server-side filesystem paths rather than copying them. Do not test with /dev/urandom, /dev/zero, or large files on production systems. Validate that disk quotas, filesystem alerts, and application logs show no unexpected growth in Gradio flagging/output directories after normal use.

Typical attack path

1. Discover an internet-accessible or internally reachable Gradio application.
2. Confirm that the flagging feature or related flag submission workflow is enabled and reachable without authentication.
3. Send a crafted flagging request that causes the server to treat an attacker-supplied path as a local file source.
4. Use a high-impact source path such as a large readable file or a special device file to force large writes into the flagging directory.
5. Repeat or sustain requests until disk space is exhausted.
6. Leverage the resulting storage exhaustion to disrupt application availability, logging, uploads, model serving, or adjacent services on the same host.

How to detect it

Review reverse-proxy, application, container, and WAF logs for unauthenticated requests to Gradio flagging-related routes or API calls that contain absolute filesystem paths, parent-directory traversal, device files, or Linux virtual filesystem paths. Pay particular attention to request bodies or parameters containing /dev/urandom, /dev/zero, /proc/, /sys/, /etc/, or unusually long path values. On hosts and containers, examine Gradio flagging/output directories for unexpected files, rapid growth, very large files, files created by the Gradio service account, or file creation times matching suspicious requests. Review system logs and application errors for disk exhaustion symptoms such as ENOSPC, "No space left on device", container eviction, failed writes, failed logging, or sudden drops to 0 bytes free. If centralized telemetry is available, correlate disk-free alerts, Gradio access bursts, and write-heavy Python/Gradio processes. Because the attacker may not receive copied contents directly, exploitation evidence is more likely to appear as abnormal file growth and storage exhaustion than as outbound data transfer.

• /dev/urandom
• /dev/zero
• /proc/kcore
• /proc/self/environ
• /etc/passwd
• /etc/shadow
• ../
• ..%2f
• ..%2F
• flagged_data
• No space left on device
• ENOSPC
• OSError: [Errno 28]
• Errno 28
• disk quota exceeded

What your security team should do

• Inventory Gradio deployments, especially internet-facing AI demos, notebook environments, and model-serving interfaces.
• Prioritize patching any exposed Gradio instance to a fixed release or source commit 16c9b246f714c03a2ece8f96515f55636700dc27 or later.
• Disable Gradio flagging if it is not operationally required.
• Require authentication and network access controls for Gradio applications, particularly those deployed for internal experiments that may have been unintentionally exposed.
• Apply filesystem quotas and disk-space monitoring to Gradio flagging, upload, temporary, and output directories.
• Review historical logs and filesystem artifacts for suspicious flagging requests referencing absolute paths, device files, or proc/sys paths.
• If exploitation is suspected, preserve application logs, reverse-proxy logs, container logs, and the contents/metadata of flagging directories before cleanup.
• Clean up unauthorized copied files and rotate any secrets if sensitive local files may have been copied into locations accessible through backups, administrative review workflows, or downstream processing.