CVE-2026-40086

What it actually does

Rembg HTTP server versions prior to 2.0.75 allow unauthenticated remote users to supply a crafted model_path parameter that is not safely constrained to the intended model directory. By using path traversal sequences, an attacker can cause the server to attempt to load arbitrary filesystem paths as ONNX model files. Even when the target file is not a valid model, loader errors may disclose whether the file exists, whether it is readable by the rembg process, and in some cases portions of file contents or parsing details. The vulnerability primarily impacts confidentiality; it does not directly provide code execution or data modification based on the available description.

Why it matters to the business

An exposed rembg HTTP server could leak sensitive local files such as configuration files, secrets, service credentials, source code, environment files, or system metadata if the rembg process can read them. The CVSS score is moderate and EPSS is currently low and flat, with no known KEV or ransomware association, but exploitation requires no authentication and can be performed remotely, so internet-facing deployments should still be prioritized for upgrade or isolation.

How an attack unfolds

An attacker first identifies a reachable rembg HTTP server and determines which endpoint accepts a model_path parameter. They then submit requests containing directory traversal payloads such as ../ sequences, encoded traversal characters, or absolute paths. The server passes the attacker-controlled path to the ONNX model-loading logic without adequately validating that the file is an approved model in an approved directory. The model loader attempts to open and parse the referenced file. If the file exists and is readable, error responses, stack traces, HTTP status differences, timing, or log output may reveal file existence, access permissions, and potentially file content fragments. The attacker repeats this process against high-value paths such as application configuration, environment files, SSH keys, cloud credentials, container secrets, and operating system files.

How to fix it

Upgrade rembg to version 2.0.75 or later. If immediate upgrade is not possible, disable public access to the rembg HTTP server, place it behind strong authentication and network allowlisting, and block requests containing traversal patterns in model_path or other file-loading parameters. Run the service as a dedicated low-privilege user with read access only to required model and working directories. Avoid mounting sensitive host paths, secrets directories, cloud credential files, or application configuration into containers running rembg. Suppress detailed error responses to clients and ensure model paths are resolved, canonicalized, and validated against a fixed allowlisted directory before use.

How to confirm the fix worked

Confirm the installed rembg version is 2.0.75 or later using package metadata, dependency lockfiles, container image manifests, or runtime startup logs. Verify that the HTTP server is not internet-exposed unless explicitly required and protected. Send a controlled test request using a harmless traversal target, such as a known non-sensitive file outside the model directory, and confirm the server rejects it without revealing file existence, permissions, stack traces, or parser details. Review dependency manifests and container images to ensure older rembg versions are not present in build artifacts. Confirm the service runs with least privilege and cannot read sensitive filesystem locations unrelated to model processing.

Typical attack path

1. Discover an exposed rembg HTTP server or API endpoint.
2. Identify a request parameter named model_path or equivalent model-loading input.
3. Send benign requests to observe normal response behavior.
4. Send crafted requests using path traversal payloads such as ../../../../etc/passwd or URL-encoded equivalents in the model_path parameter.
5. Compare HTTP status codes, response bodies, error messages, and timing to determine whether target files exist and are readable.
6. Iterate over likely sensitive file paths for the operating system, container runtime, and application deployment model.
7. Use any disclosed secrets or configuration data to support follow-on access against adjacent services.

How to detect it

Review HTTP access logs, reverse-proxy logs, API gateway logs, WAF events, and application logs for requests containing model_path parameters with traversal sequences, encoded dot-dot-slash patterns, absolute filesystem paths, or references to sensitive files. Look for repeated requests that vary only the target file path, especially requests probing /etc/passwd, /proc/self/environ, SSH keys, cloud credential paths, container secret mounts, application .env files, or Windows system paths. Check application stderr/stdout, container logs, and Python exception traces for ONNX model-loading errors involving unexpected non-model files. Investigate 400/404/500 response spikes associated with model_path inputs, particularly when followed by access attempts to other services that could indicate credential reuse from disclosed files. Because exploitation may only produce error responses and not durable host artifacts, absence of local file changes does not rule out successful information disclosure.

• model_path=../
• model_path=..%2f
• model_path=%2e%2e%2f
• model_path=..%252f
• model_path=%252e%252e%252f
• model_path=../../../../etc/passwd
• model_path=/etc/passwd
• model_path=/proc/self/environ
• model_path=/root/.ssh/id_rsa
• model_path=/home/
• model_path=.env
• model_path=/run/secrets/
• model_path=/var/run/secrets/
• model_path=/var/run/secrets/kubernetes.io/serviceaccount/token
• model_path=C:\\Windows\\win.ini
• model_path=C:/Windows/win.ini
• model_path=C:\\Windows\\System32\\drivers\\etc\\hosts
• InvalidProtobuf
• onnxruntime
• ONNX
• Failed to load model
• Load model from
• model_path

What your security team should do

• Inventory all deployments, containers, notebooks, API services, and internal tools that run danielgatis/rembg or expose the rembg HTTP server.
• Upgrade all affected deployments to rembg 2.0.75 or later.
• Prioritize remediation for internet-facing or unauthenticated rembg HTTP services.
• Restrict network access to the rembg HTTP server with authentication, private networking, VPN, reverse-proxy controls, or allowlists.
• Add WAF, reverse-proxy, or API gateway rules to block model_path requests containing traversal sequences, URL-encoded traversal, absolute paths, or references to sensitive filesystem locations.
• Harden runtime permissions so the rembg process cannot read secrets, host filesystems, cloud credentials, or unrelated application configuration.
• Review recent access logs for suspicious model_path values and repeated probing of sensitive paths.
• Disable verbose client-facing error messages and stack traces in production deployments.