GHSA-55v6-g8pm-pw4c

What it actually does

The rembg server can be abused as a Server-Side Request Forgery proxy when it accepts attacker-controlled image locations and retrieves them from the server side. Because the default CORS policy is weak, an attacker-controlled website may be able to make cross-origin requests to the rembg server from a victim browser and read the returned image response. In practice, this can expose image-renderable resources reachable only from the rembg server’s network, including internal web services, administrative panels that return images, screenshots, generated charts, or metadata-like endpoints if their response can be processed as an image. The impact is constrained by what the rembg server is allowed to fetch, what response formats it accepts, and whether authentication or network egress controls are in place.

Why it matters to the business

An exposed rembg server could let an external attacker use the service as a bridge into internal networks and retrieve sensitive visual content from systems that were not intended to be reachable from the internet. While the CVSS score is moderate and there is no current KEV listing or known public exploit maturity in the provided data, the issue can still create meaningful data-exposure risk for organizations running rembg server in network-adjacent or internet-accessible deployments, especially where it can reach internal applications or cloud control-plane endpoints.

How an attack unfolds

An attacker first identifies a reachable rembg server that accepts user-supplied image input, such as a URL or remote image reference. The attacker then creates a malicious web page that causes a visitor’s browser to send requests to the rembg server. Due to the permissive default CORS behavior, the attacker’s page may be allowed to read the response. The request instructs the rembg server to fetch an internal URL, making the request originate from the rembg server’s network position rather than the attacker’s machine. If the internal service returns content that the rembg server treats as an image or can transform into an image response, the result is returned to the browser and exposed to the attacker-controlled page. Repeating this process can allow discovery of internal services and extraction of image-based or image-compatible internal content.

How to fix it

Upgrade rembg server to a version that corrects the SSRF and CORS behavior when an official fixed release is available. If no fixed version is available for the deployed package, apply compensating controls immediately: disable remote URL fetching if it is not required; only allow image retrieval from explicitly trusted domains; reject private, loopback, link-local, multicast, and cloud metadata address ranges; block redirects to disallowed networks; enforce strict scheme handling such as HTTPS-only where possible; limit accepted content types and response sizes; and require authentication for access to the server. Replace wildcard or reflective CORS behavior with a strict allowlist of trusted origins, and avoid allowing credentials unless absolutely necessary. Network-level egress filtering should prevent the rembg server from reaching internal administrative networks, cloud metadata services, and other sensitive endpoints.

How to confirm the fix worked

Confirm whether the running rembg server version or commit includes an upstream fix if one has been released. Review configuration and runtime behavior to ensure CORS responses do not allow arbitrary origins and do not expose responses to untrusted websites. From a controlled test client, attempt to submit image URLs pointing to loopback, RFC1918 private ranges, link-local addresses, and cloud metadata endpoints; the server should reject these before making outbound requests. Validate that redirects from allowed external URLs to internal destinations are blocked. Review firewall or container egress rules to verify that the rembg server cannot connect to sensitive internal subnets or metadata services. If the service is exposed through a reverse proxy, confirm authentication, origin restrictions, and request logging are enabled.

Typical attack path

1. Identify an internet-accessible or browser-reachable rembg server instance.
2. Confirm the service accepts attacker-controlled image sources or remote image URLs.
3. Host or deliver a malicious web page that issues cross-origin requests to the rembg server.
4. Use the rembg server to request internal network URLs or restricted resources from its server-side network location.
5. Leverage the permissive CORS behavior to read the returned image response from the attacker-controlled page.
6. Iterate across internal addresses, ports, or known service paths to discover and retrieve additional reachable image responses.

How to detect it

To determine whether exploitation has already occurred, review rembg server HTTP access logs, reverse proxy logs, application logs, DNS logs, and outbound firewall or proxy telemetry. Look for requests that submit remote image URLs pointing to internal IP ranges, localhost, link-local addresses, unusual ports, or cloud metadata addresses. Correlate inbound requests to the rembg server with outbound connections from the rembg host shortly afterward, especially to RFC1918 addresses, 127.0.0.0/8, 169.254.0.0/16, ::1, fc00::/7, or internal hostnames. Inspect HTTP responses where CORS headers allowed untrusted origins to read content. Pay special attention to requests with unexpected Origin headers, high-volume probing across many internal addresses or ports, repeated failed image fetches, or successful image processing responses sourced from non-public network destinations. Because no specific threat actors, ransomware use, or stable exploit strings are provided, detection should focus on behavioral evidence of SSRF and CORS abuse rather than a single signature.

• 169.254.169.254
• metadata.google.internal
• 100.100.100.200
• 169.254.169.254/latest/meta-data
• 169.254.169.254/metadata/instance
• 127.0.0.1
• localhost
• Access-Control-Allow-Origin: *
• Origin: null

What your security team should do

• Inventory all rembg server deployments, prioritizing internet-exposed instances and services reachable from user browsers.
• Restrict CORS immediately to known trusted origins; remove wildcard or origin-reflecting behavior.
• Disable remote image URL ingestion unless required; prefer direct file upload from authenticated users.
• Implement SSRF defenses: destination allowlists, private-address blocking, redirect validation, content-type validation, and response-size limits.
• Apply network egress controls so the rembg server cannot reach internal management networks, cloud metadata services, or sensitive application tiers.
• Monitor rembg server access logs and outbound network telemetry for unusual requests to internal IP ranges, localhost, link-local addresses, or metadata endpoints.
• Place the service behind authentication and rate limiting if it must remain reachable.
• Track upstream advisories for fixed rembg server versions and upgrade promptly when a patched release is available.