Description

is_path_trusted in scripts/iib/api.py compares the requested path against each allowed parent directory with path.startswith(parent_path), 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/images_private/secret.txt is treated as trusted and served by FileResponse, disclosing files the confinement was meant to exclude. Whether the check applies depends on get_enable_access_control in scripts/iib/tool.py: it returns true when IIB_ACCESS_CONTROL 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 server_name, 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 parent_path joined with os.sep.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-21T15:16:47.733Z",
  "pubdate": "2026-08-21T15:16:47.733Z",
  "executiveSummary": "A path traversal vulnerability exists in the IIB (Image Information Brooder) extension for Stable Diffusion WebUI, specifically within the `is_path_trusted` function located in scripts/iib/api.py. The flaw arises from improper validation of requested file paths against allowed parent directories using string prefix comparison without a trailing path separator.\nThis vulnerability allows an unauthenticated remote attacker to bypass intended directory confinement restrictions and read arbitrary files from the host operating system that the underlying process has read permissions for.\nThe risk is particularly high in network-exposed deployments where access control mechanisms are automatically enabled. Confinement is active when the `IIB_ACCESS_CONTROL` environment variable is set to enable, or automatically when the host Stable Diffusion WebUI is launched with command-line flags such as share, ngrok, listen, or server_name. Standalone local runs without these options default to disabled access control, though the logic flaw remains present when confinement is enforced.\nAn attacker can exploit this by requesting files located within a directory whose name merely shares a common prefix with an explicitly allowed parent directory, thereby gaining unauthorized access to sensitive data.",
  "technicalDetails": "The vulnerability resides in the path validation logic implemented by the `is_path_trusted` function inside scripts/iib/api.py. When processing file requests destined for `FileResponse`, the application checks if the requested path falls within a set of permitted parent directories.\nThe root cause of the flaw is the insecure use of the Python string method `path.startswith(parent_path)` to verify directory containment. Because `startswith()` performs a strict lexical prefix comparison without ensuring that the match terminates at a directory boundary (i.e., lacking a trailing path separator such as `os.sep`), any directory name that begins with the exact character sequence of an allowed parent directory will improperly evaluate as trusted.\nFor example, if `/data/images` is explicitly defined as an allowed parent directory, a malicious request targeting `/data/images_private/secret.txt` will satisfy the `path.startswith('/data/images')` condition. Consequently, the application treats the traversal attempt as legitimate and serves the arbitrary file outside the intended containment zone via `FileResponse`.\nWhether this vulnerability can be successfully leveraged depends on the state of access control enforcement governed by `get_enable_access_control` in scripts/iib/tool.py. This function returns true if the `IIB_ACCESS_CONTROL` environment variable is explicitly set to enable, false if set to disable, and defaults to true if the parent Stable Diffusion WebUI instance was initiated with exposure flags including share, ngrok, listen, or server_name. If none of these conditions are met, access control defaults to false, exposing all readable files regardless of the flaw.\nTo exploit this vector, an attacker crafts an HTTP request pointing to a path that leverages the string prefix collision vulnerability. Upon reception, the vulnerable API parses the input, fails to recognize the boundary violation due to the missing path separator check, and returns the contents of the targeted sensitive file in the response body, leading to unauthorized information disclosure."
}