GPU VulnDB

Database/AI/ML frameworks & serving

Rembg: unauthenticated /api/remove parameter pulls attacker-chosen ONNX models and leaks local files

CVSS 8.6CVE-2026-115924AI/ML frameworks & servingcurated

Impact

The public /api/remove endpoint passes extras.sam_model straight into SAM model filenames and GitHub download URLs handed to pooch.retrieve() with no pinned hash, so an unauthenticated caller can combine path traversal with URL-fragment syntax (the HTTP fetch drops the fragment, the local POSIX path keeps it) to make the server download attacker-supplied ONNX encoder and decoder files next to a chosen file. Those graphs then load the target file through ONNX external data and encode its bytes into the returned PNG mask. In practice that is arbitrary file disclosure for anything the rembg process can read - service tokens, cloud credential files, other tenants' inputs in a shared volume - plus arbitrary ONNX computation executing in the inference process on a GPU node. Versions prior to 2.0.82 are affected.

Who can reach it

Any client that can reach the rembg HTTP API, unauthenticated, with no user interaction. Worst where the service is exposed beyond the cluster, but a tenant pod that can reach it in-cluster is enough.

What to do

Upgrade to rembg 2.0.82 and restart the service; this is a container image bump and a daemon restart, no node drain. Until the rollout lands, put authentication or a network policy in front of the API, and run the process with a minimal filesystem view and no mounted credentials so a read primitive returns nothing useful. Egress-restricting the pod also breaks the malicious-model download step.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.