Unrestricted App-Directory File Read via Gradio 3.41.2 /file= (CVE-2023-51449 Exposure)

Checklist

• The issue has not been resolved by following the troubleshooting guide
• The issue exists on a clean installation of Fooocus
• The issue exists in the current version of Fooocus
• The issue has not been reported before recently
• The issue has been reported before but has not been fixed yet

What happened?

Summary

Fooocus pins Gradio 3.41.2, which is vulnerable to CVE-2023-51449 (fixed in 4.11.0). The Gradio /file= endpoint allows reading any file under the application's working directory without restriction. In Fooocus, the working directory is the installation directory, which contains auth.json (plaintext passwords), config.txt (API keys, model paths), wildcard text files, preset configurations, and style files. An unauthenticated attacker can retrieve all of these. Fooocus has no authentication by default and is designed to listen on 0.0.0.0.

Details

Gradio 3.41.2 routes.py lines 369-378 check whether a requested path is allowed:

in_app_dir = utils.is_in_or_equal(abs_path, app.cwd)
created_by_app = str(abs_path) in set().union(*blocks.temp_file_sets)
in_allowlist = any(...)
was_uploaded = utils.is_in_or_equal(abs_path, app.uploaded_file_dir)

if not (in_app_dir or created_by_app or in_allowlist or was_uploaded):
    raise HTTPException(403, f"File not allowed: {path_or_url}.")

The in_app_dir condition allows any file under app.cwd (the current working directory of the Gradio application). Fooocus sets os.chdir(root) in launch.py line 9, where root is the directory containing Fooocus's source code. This means all files in the Fooocus installation directory are served unconditionally.

Gradio 4.11.0 fixed CVE-2023-51449 by removing in_app_dir from the allowlist, leaving only created_by_app, in_allowlist, and was_uploaded as valid reasons to serve a file.

Sensitive files readable in a default Fooocus installation:

• auth.json -- user credentials (plaintext passwords per the example auth-example.json format)
• config.txt -- user configuration including custom model paths and any API keys added by the user
• wildcards/*.txt -- wildcard prompt files (may contain user-defined content)
• presets/*.json -- preset configurations
• sdxl_styles/*.json -- style definitions
• Any Python source file in the installation

Steps to reproduce the problem

PoC

Prerequisites: Fooocus running with --listen (default Docker mode). No authentication required.

Read the auth credentials file (in Docker, Fooocus installs to /content/app):

GET /file=/content/app/auth.json HTTP/1.1
Host: FOOOCUS_HOST:7865

Response:

[{"user": "admin", "pass": "super_secret_password_123"}]

Read the config file (may contain API keys):

GET /file=/content/app/config.txt HTTP/1.1
Host: FOOOCUS_HOST:7865

Response:

{"default_model": "JuggernautXL.safetensors", "path_checkpoints": "/content/data/models", "openai_api_key": "sk-proj-abc123xyz"}

Both requests return HTTP 200 with file contents. Live validated on commit ae05379 with Gradio 3.41.2.

For standalone installations (non-Docker), the working directory is wherever Fooocus is installed, which may contain additional sensitive files depending on the user's configuration.

Impact

Any unauthenticated network-reachable peer can read the entire Fooocus installation directory tree. This leaks plaintext user credentials from auth.json, API keys from config.txt, and all configuration files. Combined with the SSRF finding (002), the attacker can map internal network services and exfiltrate their responses. The fix is to upgrade the pinned Gradio dependency from 3.41.2 to at least 4.11.0.

What should have happened?

What browsers do you use to access Fooocus?

No response

Where are you running Fooocus?

None

What operating system are you using?

No response

Console logs

-

Additional information

No response