GHSA-55V6-G8PM-PW4C: Server-Side Request Forgery and CORS Misconfiguration in rembg API

The rembg package provides a utility for removing backgrounds from images. When executed as a server, it exposes an HTTP API endpoint at /api/remove designed to process remote images via a url parameter. This endpoint suffers from a Server-Side Request Forgery (SSRF) vulnerability tracked as CVE-2025-25301.

Simultaneously, the API implements a flawed Cross-Origin Resource Sharing (CORS) configuration, tracked as CVE-2025-25302. The application utilizes the FastAPI CORSMiddleware configured to allow all origins while simultaneously permitting credentials. This violates security standards regarding cross-origin communication.

These vulnerabilities allow an external attacker to interact with the server in unintended ways. An attacker can supply internal network destinations to the SSRF endpoint, forcing the server to issue HTTP requests to internal subnets. The CORS misconfiguration expands the attack surface by enabling cross-site exploitation vectors.

The SSRF vulnerability originates in the routing logic for the /api/remove endpoint. The application accepts a user-provided string via the url parameter and passes it directly into an asynchronous HTTP client operation. The system instantiates an aiohttp.ClientSession and performs a GET request without verifying the scheme, hostname, or resolved IP address.

Because the underlying aiohttp client executes the request exactly as provided, it treats internal IP addresses and loopback interfaces as valid destinations. The application subsequently reads the HTTP response and feeds it into the background removal processing pipeline. This creates a direct conduit for an attacker to issue requests from the context of the server.

For the CORS vulnerability, the root cause is a misconfigured middleware definition. The application defines allow_origins=["*"] alongside allow_credentials=True. Modern browsers typically block this exact combination to prevent malicious origins from reading credentialed cross-origin responses, but older or improperly configured environments may still evaluate it, and it clearly indicates an overly permissive security posture.

Prior to version 2.0.75, the rembg command handler blindly requested user-provided URLs. The get_index asynchronous function extracted the query parameter and invoked session.get(url). The following snippet illustrates the vulnerable implementation.

# Vulnerable implementation in rembg/commands/s_command.py
async def get_index(
    url: str = Query(default=..., description="URL of the image..."),
    commons: CommonQueryParams = Depends(),
):
    async with aiohttp.ClientSession() as session:
        async with session.get(url) as response:
            file = await response.read()
            return await asyncify(im_without_bg)(file, commons)

The maintainers addressed these issues in commit 07ad0d493057bddf821dcc3e2410eb7e065257c0. The patch modifies the CORSMiddleware configuration by setting allow_credentials=False. It also introduces URL validation logic to mitigate the SSRF, implementing _validate_url and _is_private_ip functions.

# Patch implementation restricting cross-origin requests
app.add_middleware(
    CORSMiddleware,
    allow_credentials=False,  # Patched from True
    allow_origins=["*"],
    allow_methods=["*"],
    allow_headers=["*"],
)

The SSRF patch ensures the URL scheme is strictly HTTP or HTTPS and attempts to resolve the provided hostname. The resolved addresses are checked against reserved ranges using the Python ipaddress module. If a private or loopback IP is detected, the server rejects the request before establishing the aiohttp connection.

An attacker exploits the SSRF by identifying a target instance of the rembg server and sending an HTTP GET request to /api/remove with a crafted url parameter. A common payload targets the cloud provider metadata service. For example, submitting url=http://169.254.169.254/latest/meta-data/ forces the server to fetch its own cloud environment credentials.

Security researchers identified structural weaknesses in the provided patch for version 2.0.75. The _validate_url function performs DNS resolution via socket.getaddrinfo to check for private IPs. However, the subsequent aiohttp.ClientSession.get() call performs its own independent DNS resolution. This architecture creates a Time-of-Check to Time-of-Use (TOCTOU) vulnerability.

An attacker can execute a DNS Rebinding attack by hosting a custom DNS server. During the validation phase, the DNS server returns a benign public IP address. Milliseconds later, when aiohttp resolves the domain for the actual request, the DNS server returns a private internal IP address, bypassing the patch entirely. Additionally, because aiohttp follows redirects by default, an attacker can supply an external URL that redirects to an internal IP, evading the initial validation check.

The successful exploitation of CVE-2025-25301 grants unauthorized network visibility from the perspective of the application server. Attackers map internal subnets, discover administrative interfaces, and interact with microservices that lack authentication boundaries. This lateral movement capability compromises network isolation models.

If the server processes the fetched payload and reflects portions of the data back to the client, the vulnerability escalates to data exfiltration. Attackers retrieve sensitive configuration files, internal API responses, or cloud IAM tokens. The severity of the information disclosure depends heavily on the deployment environment and the exact behavior of the image processing routine.

The inclusion of CVE-2025-25302 compounds the risk profile. The permissive CORS implementation allows any malicious webpage visited by a victim to silently issue requests to the rembg server. If the target deployment relies on session cookies or intranet-based IP authentication, attackers leverage the victim's browser to pivot into the application.

System administrators must upgrade rembg to version 2.0.75 or later. This release enforces a restrictive CORS policy and provides baseline protection against trivial SSRF payloads. Upgrading is the primary administrative action required to resolve the publicly disclosed advisory.

Due to the known bypasses involving DNS rebinding and HTTP redirects, upgrading the software is insufficient for complete protection. Organizations must deploy the rembg API server within an isolated network environment. Implement egress firewall rules that explicitly deny outbound connections to internal subnets, loopback addresses, and cloud metadata IP ranges.

Security teams should configure Web Application Firewalls (WAF) to inspect the url query parameter on the /api/remove endpoint. Create rules to drop requests containing local network identifiers, obvious metadata IP addresses, or excessively short TTL domains commonly associated with DNS rebinding frameworks.