CVE-2026-77814: Infinite Image Browsing is_path_trusted Prefix Comparison Omits the Trailing Path Separator
ispathtrusted in scripts/iib/api.py compares the requested path against each allowed parent directory with path.startswith(parentpath), without appending a path separator. A directory whose name merely begins with an allowed path therefore satisfies the comparison, so where /data/images is allowed a request for /data/imagesprivate/secret.txt is treated as trusted and served by FileResponse, disclosing files the confinement was meant to exclude. 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 compares against parentpath joined with os.sep.
Affected Software
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this bypass?
Network-exposed Stable Diffusion WebUI deployments started with share, ngrok, listen, or server_name enable access control by default and can be affected. Deployments with IIB_ACCESS_CONTROL set to enable are also affected if they rely on allowed-directory confinement.
What does an attacker need to exploit the issue?
An attacker only needs network access to make a request for a readable file located under a directory whose path starts with an allowed parent path. For example, allowing /data/images can incorrectly trust /data/images_private/secret.txt.
Are standalone deployments protected by the access-control setting?
A standalone run without share, ngrok, listen, or server_name defaults to access control disabled unless IIB_ACCESS_CONTROL is explicitly set to enable. In that configuration, every readable file is served regardless of this specific prefix-comparison flaw.
What can be done before applying the fix?
Avoid exposing the WebUI over the network using share, ngrok, listen, or server_name, or otherwise restrict network access to trusted users. Review allowed parent directories for similarly prefixed sibling directories containing sensitive readable files.
How can I determine whether a deployment contains the vulnerable check?
Inspect scripts/iib/api.py for an is_path_trusted check using path.startswith(parent_path) without joining parent_path with os.sep. The corrected logic compares against parent_path joined with os.sep.