CVE-2026-77815: Infinite Image Browsing Resolves Paths With normpath, Allowing Symlink Escape From Scanned Directories
toabspath in scripts/iib/tool.py normalised the requested path with os.path.normpath, which collapses dot segments but does not resolve symbolic links. A symlink placed inside a scanned directory therefore satisfies the containment comparison performed by ispathtrusted in scripts/iib/api.py while pointing outside that directory, and FileResponse follows the link when serving the response, so a link created in an image directory and targeting a file such as /etc/passwd discloses that file. Whether the check applies depends on getenableaccesscontrol in scripts/iib/tool.py: it returns true when IIBACCESSCONTROL is set to enable, false when set to disable, and otherwise true when the host Stable Diffusion WebUI was started with share, ngrok, listen or servername, falling back to false. Confinement is therefore active in the network-exposed WebUI deployments that rely on it, while a standalone run with no such option serves every readable file regardless of this flaw. The fix resolves the path with os.path.realpath.
Affected Software
Event History
Frequently Asked Questions
Which deployments are realistically exposed to the symlink escape?
Network-exposed Stable Diffusion WebUI deployments started with share, ngrok, listen, or server_name are affected when they rely on Infinite Image Browsing access control to confine file access. A standalone deployment without those options does not enable that confinement by default and can serve any readable file regardless of this specific bypass.
What does an attacker need to exploit the issue?
The attacker needs a symbolic link inside a scanned image directory that points to a readable file outside that directory. Requesting the link causes FileResponse to follow it and return the target file.
How can I tell whether access control is enabled?
IIB_ACCESS_CONTROL=enable explicitly enables it, while IIB_ACCESS_CONTROL=disable disables it. If the variable is unset, it is enabled only when the host WebUI was started with share, ngrok, listen, or server_name; otherwise it is disabled.
What can be done before applying the fix?
Prevent untrusted users or processes from creating symlinks in scanned directories, and remove or audit existing symlinks there. Restrict network exposure of the WebUI and avoid relying on the affected containment check to protect files outside scanned directories.