CVE-2024-4888 is a high severity flaw in BerriAI's LiteLLM, scored 8.1. The /audio/transcriptions endpoint deletes a file whose name comes from the request. Authenticated users can remove server files. The record gives no fixed version, so check LiteLLM's releases.
What's affected
The record says LiteLLM "in its latest version" at the time was affected, with a wildcard product match, so it does not pin a range. The vulnerable pattern is a call to os.remove(file.filename) in the transcription handler. That means the name supplied by the client is used for a delete on the server's file system.
The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H: network reachable, low complexity, a low privilege account, and high integrity and availability impact. The record's text says "any user", while the vector says low privileges. Both point at a user with a valid API key rather than an anonymous visitor, but the wording is loose.
Fixed version: the only reference is a huntr bounty page, which did not load usable text for me. I cannot name a patched release. Check LiteLLM's release notes and commit history.
The weakness is CWE-862, missing authorization.
How to check if you're exposed
LiteLLM is usually a Python package or a proxy container. Find versions:
pip show litellm
pip list 2>/dev/null | grep -i litellm
For containers, inspect the image tag in your compose files or Kubernetes manifests. Then ask two questions: is the proxy exposed to anyone beyond trusted services, and does the process run with write access to anything important? Deleting a file requires write permission on its directory, so a locked down service account limits the damage.
What to do now
- Inventory LiteLLM packages and proxy containers, including those in notebooks and internal tools.
- Move to a release that the maintainers say addresses the transcription endpoint, once you have confirmed it in the notes.
- If you do not use audio transcription, block the route at the gateway.
- Run the proxy as a dedicated user with write access only to its own working directory, and mount config and key files read only.
- Back up the proxy's SQLite or other state, because the record names databases and keys as targets.
Why it matters
Missing authorization here means the delete happens without checking that the caller may touch that path. Request handling code should never pass a client chosen name straight to a file operation. The usual fix is to generate a server side file name and keep uploads in a scratch directory.
An LLM gateway holds provider keys and a lot of state, so deleting a config file or database can turn into an outage across every application that routes through it. The record lists SSH keys, SQLite databases and configuration files as examples.
The record does not mark this CVE as exploited in the wild and it is not in the CISA KEV catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to be anonymous or logged in to exploit this?
The vector says low privileges, so a valid account or key is assumed, though the description says "any user".
What does the fix look like?
Not confirmed from the record. Expect server side file naming or removal of the delete, and check the project's notes.
Sources
- huntr bounty report (page content could not be retrieved)
- NVD record for CVE-2024-4888
Last reviewed: 19 October 2026.
