Skip to content

fix: prevent symlink-based path traversal in /view endpoint #12287

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
Mr-Neutr0n wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix: prevent symlink-based path traversal in /view endpoint #12287

Mr-Neutr0n wants to merge 1 commit into from
+4 −1

Conversation

@Mr-Neutr0n
Copy link

@Mr-Neutr0n Mr-Neutr0n commented Feb 4, 2026

Summary

This PR fixes a symlink-based path traversal vulnerability in the /view endpoint that could allow attackers to read arbitrary files from the server filesystem.

Problem

The path validation using os.path.commonpath() occurred before symlink resolution. An attacker could:

  1. Create a symlink in an allowed directory (input/output/temp) pointing to any location
  2. Access files through that symlink, bypassing the path check

Example attack:

ln -s /etc input/etc_link
curl "http://localhost:8188/view?filename=passwd&subfolder=etc_link&type=input"
# Returns contents of /etc/passwd

Solution

Resolve symlinks using os.path.realpath() before validating that the path is within allowed directories.

Changes

  • Added symlink resolution before path validation in /view endpoint
  • Uses os.path.realpath() to get the canonical path
  • Validates resolved path starts with the allowed base directory

Testing

  • Verified legitimate subfolder access still works
  • Verified symlink attacks are now blocked with 403 response
  • No breaking changes to existing functionality

Fixes #12285

🤖 Generated with Claude Code

@Mr-Neutr0n @claude
fix: prevent symlink-based path traversal in /view endpoint
d50064a 
Resolve symlinks before path validation to prevent attackers from
using symlinks to read arbitrary files outside allowed directories.

Previously, os.path.commonpath() validation occurred before symlink
resolution, allowing attackers to create symlinks in input/output/temp
directories pointing to sensitive files like /etc/passwd or SSH keys.

The fix uses os.path.realpath() to resolve symlinks before checking
if the path is within allowed directories.

Fixes Comfy-Org#12285

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@Mr-Neutr0n
Copy link
Author

Mr-Neutr0n commented Feb 4, 2026

Security Impact Assessment

Severity: High

This vulnerability allows arbitrary file read from the server filesystem. In a typical ComfyUI deployment, this could expose:

  • SSH keys (~/.ssh/id_rsa) - enables lateral movement
  • Cloud credentials (~/.aws/credentials, ~/.config/gcloud/) - cloud account compromise
  • Environment files (.env) - API keys, database passwords
  • Application secrets - other services running on the same machine

The attack requires the ability to create symlinks in ComfyUI's input/output/temp directories, which is possible if:

  1. The attacker has local access
  2. ComfyUI allows file uploads that could create symlinks
  3. Custom nodes create symlinks

Happy to add additional test cases if needed. Thanks for reviewing!

@Ken-g6
Copy link

Ken-g6 commented Feb 5, 2026

I like to make my input/output/temp directories symlinks to a ramdisk. This reduces SSD writes and cleans up files I don't copy elsewhere whenever I reboot. Would your proposed fix interfere with that?

@Mr-Neutr0n
Copy link
Author

Mr-Neutr0n commented Feb 6, 2026

@Ken-g6 Great question! No, this fix wouldn't interfere with your setup.

The fix only validates that files being accessed resolve to within the configured directories. If your input/output/temp directories are symlinks to a ramdisk, that's fine - the validation happens after symlink resolution, so:

  • input/ → /mnt/ramdisk/comfy_input/ ✅ Works fine
  • Files inside input/ would be validated against /mnt/ramdisk/comfy_input/ ✅

What this fix prevents is:

  • input/malicious_link → /etc/passwd ❌ Blocked (resolves outside configured dirs)
  • input/../../.ssh/id_rsa ❌ Blocked (path traversal)

So your ramdisk symlink setup would continue to work exactly as before. The security check only kicks in when a file inside the directory tries to escape to an unexpected location.

@Mr-Neutr0n
Copy link
Author

Mr-Neutr0n commented Feb 9, 2026

hey, following up on the symlink path traversal fix. this is separate from the pickle issue (which i closed). the symlink check prevents /view from serving files outside the output directory

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@comfyanonymous comfyanonymous Awaiting requested review from comfyanonymous comfyanonymous is a code owner

@Kosinkadink Kosinkadink Awaiting requested review from Kosinkadink Kosinkadink is a code owner

@guill guill Awaiting requested review from guill guill is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Security: Symlink Path Traversal in /view endpoint allows arbitrary file read

2 participants

@Mr-Neutr0n @Ken-g6