如何檢查 Mac 是否安裝遭篡改的 LiteLLM 1.107.0

📝 Originally published (in Japanese) at forge.workstyle.tech.

TL;DR: LiteLLM 1.107.0 distributed through PyPI was tampered with. On a Mac, check the installed version in each Python environment, then search for three files and indicators of infection. The article also explains why Spotlight can miss files and how to distinguish a malicious sitecustomize.py from a legitimate one.

Conclusion First

The affected environments are those where the tampered version 1.107.0 was installed. To verify this, check the installed version, three specific files, and the infection markers. If the compromised version was present, simply deleting the files and processes is not enough; you must also rotate any secret keys or tokens that were readable from the terminal.

Which Version is Dangerous?

The affected package is litellm==1.107.0 on PyPI. Both the sdist and wheels for Linux, macOS, and Windows were compromised. It was published around 20:39 JST on October 21 and removed from PyPI around 22:40 JST.

After learning about the news, I separately checked my own gateway and an AI tool that depends on LiteLLM. First, I verified the version in each Python environment. Assuming the virtual environment path is <venv>, you can run:

<venv>/bin/pip show litellm

Check the line starting with Version:. If pip show isn't available, the name of the litellm-*.dist-info file in the environment's site-packages directory can also provide a clue.

In my gateway, I found litellm-1.92.0.dist-info. I also checked another tool and uv's cache, both of which were at version 1.92.0. Once the version is confirmed, ensure that the startup script doesn't automatically update the package. My startup script only included logic to run LiteLLM in the virtual environment, with no installation or update processes.

Where to Find the Three Files

Malicious files are installed in Python's site-packages. Their names are cook.pth, cook.py, and sitecustomize.py. Since .pth and sitecustomize.py are loaded when Python starts, they may work even in processes that do not import LiteLLM.

On a Mac, you can also try searching with Spotlight.

mdfind -name cook.pth
mdfind -name sitecustomize.py

However, even if nothing is displayed, it does not necessarily mean that the files are not present. This is because Spotlight (mdfind) does not search hidden folders like .venv, ~/.cache, or ~/.local. I also did not get any results with Spotlight. Next, I used find to directly search my home directory, Python installation location, Homebrew location, and other places.

find ~ /opt/homebrew /usr/local /Library/Frameworks/Python.framework \
  \( -name "cook.pth" -o -name "cook.py" -o -name "sitecustomize.py" -o -name "litellm-*.dist-info" \) \
  -print 2>/dev/null

Searching a wide range of targets can take a long time. Excluding large folders like photos, videos, and iCloud using -prune can speed up the search. Be sure to include the locations where you installed Python and the cache used by tools in your search targets. The same approach applies to Linux; just replace the Mac-specific search locations with the locations where you installed Python and tools in your Linux environment.

What to Look for If You Find sitecustomize.py

Just seeing the filename sitecustomize.py isn't enough to determine whether a machine is infected. I found five instances of it on my system, but they turned out to be part of legitimate tools and standard Python environments. Instead of relying on the filename alone, you need to check the file's hash and contents.

Calculate the SHA-256 hash for each file using the following command:

shasum -a 256 /path/to/sitecustomize.py

Compare the resulting value against the malicious file hashes published in SafeDep's analysis report. I won't list the hashes in this post, but the analysis report contains the full list of malicious hashes along with more details.

Next, search the file's contents:

grep -i -E "remote_code_loader|PRIVCOLLECT|litellm\.dev" /path/to/sitecustomize.py

None of the five files I found matched the malicious hashes in the report, nor did they contain any of the indicator strings searched above. When inspecting these files, don't jump to conclusions based on the filename alone—always verify it alongside the hash and contents.

Checking for Marker Files and Processes

Next, we confirm the signs of sent stolen data and the operation of resident processes.

ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock

We do not finish our judgment just because neither of them exists, and we also investigate the processes. The sitecustomize.py at the time of infection creates a resident process that is separated from the parent process. One of the conditions for the marker is "the parent is a Python process with PID 1".

ps -axo pid,ppid,lstart,command | awk '$2==1' | grep -i python

Here, we would like to note that even if the parent has PID 1, it does not necessarily mean it is suspicious. A process that is resident with launchd also has a parent with PID 1. Please check the command line in the output and confirm whether it is a process you started. In my case, the Python process with PID 1 as its parent was a gateway started by launchd.

Verify Environment Variables and Communication as Well

We also look for the environment variable PRIVCOLLECT_ACTIVE=1 as a landmark. Since macOS does not have /proc, we check the environment variables of processes using ps eww -ax.

ps eww -ax | grep "[P]RIVCOLLECT_ACTIVE=1"

At first, I ran ps eww -ax | grep -c PRIVCOLLECT_ACTIVE and was surprised to find the result was 2. This was because grep itself and the line of the shell command that included the search command were being counted. When I re-counted, excluding the line of the search command, the result was 0. By writing the first character as [P] as shown above, grep itself does not match. Please check not only the count but also the contents of the displayed lines.

If you want to investigate the communication destination, you can do so as follows:

lsof -i -n -P | grep -i python

I confirmed that the only listener was 127.0.0.1:4000. We make a judgment based on the combined results of these verifications.

What to do if you had version 1.107.0

The malicious code steals SSH keys, cloud credentials, AI tool tokens, passwords and history stored in browsers, environment variables, and API keys located in the LiteLLM proxy database, sending them to the attacker's server. The domain mentioned in the analysis report is www.litellm[.]dev. This is not the official LiteLLM domain.

If you had version 1.107.0 installed, simply deleting the three files is insufficient. You must stop any resident processes, delete the marker file, and treat all secrets readable from that terminal as compromised. You will then need to regenerate your SSH keys, cloud keys, AI tool tokens, saved passwords, and API keys for the various services. For a detailed analysis and the hashes of the malicious files, please refer to the SafeDep analysis article.

I did not find version 1.107.0 in the environments I investigated, nor could I confirm the presence of the three files or the marker. Since LiteLLM was installed across multiple environments, I did not stop after looking at just one virtual environment; I also investigated the tool's environments and caches.

Key takeaways

• Check each environment with pip show litellm or look for litellm-*.dist-info.
• Use find to search for cook.pth, cook.py, and sitecustomize.py; continue if Spotlight finds nothing.
• Compare sitecustomize.py hashes and contents with the analysis article; do not judge by filename alone.
• Check the two indicator files, PRIVCOLLECT_ACTIVE=1, and Python processes with parent PID 1; inspect the command line when PID 1 is the parent.
• If 1.107.0 was installed, stop the process and rotate keys or tokens for secrets the machine could read.