Rotate your AI keys after the LiteLLM breach

You are helping me find out whether my computer was hit by the poisoned LiteLLM release of 21 October 2026, and what I need to rotate. Work like a careful incident responder on a friend's laptop: find the facts, change nothing without my yes, and never put a secret on screen. A key printed into this conversation can end up in logs, so that rule beats every other instruction here.

THE FACTS TO WORK FROM (from LiteLLM's incident post and StepSecurity's analysis, both 21 October 2026)
- Bad version: litellm 1.107.0 on PyPI, live from 11:39 to 13:23 UTC on 21 October 2026. LiteLLM says all earlier versions are safe, and 1.107.0rc1 and rc2 were reported clean. Safe pin: litellm==1.106.2.
- Bad Docker images: litellm tags v1.107.0, latest, main-latest and main-stable from 11:46 UTC on 21 October 2026 (Docker Hub until 14:20 UTC, GHCR until 13:51 UTC) (ghcr.io/berriai/litellm, litellm-database, litellm-non_root, and docker.io/litellm/litellm).
- Signs of infection: cook.pth, cook.py or an unexpected sitecustomize.py in any site-packages folder; a folder named litellm-1.107.0.dist-info; the file /tmp/.pc_once_72129118c59f5636c0bb; the file /tmp/remote_code_loader.lock.
- Starting Python in an infected environment runs the stealer again. That includes pip, pytest, python -c, and any tool written in Python.
- If you find newer guidance from LiteLLM that contradicts this list, tell me and follow theirs.

ABOUT ME (I fill this in once; any line can say "not stated")
- My computer: [e.g. "MacBook, macOS", "Windows 11 with WSL", "Ubuntu laptop"]
- Where my code lives: [e.g. "~/code", "~/Projects and ~/work", "not stated"]
- How I install Python things: [e.g. "uv", "pip with venvs", "conda", "pipx", "not sure"]
- AI tools I have installed that might be written in Python: [e.g. "aider, dspy, open-interpreter, Google ADK, CrewAI", "not sure"]
- Do I run LiteLLM myself: [e.g. "yes, as a proxy in Docker", "yes, inside one project", "no", "not sure"]
- Did I install or update any Python packages, or pull a LiteLLM image, on 21 October 2026: [e.g. "yes, ran uv sync that morning", "no", "cannot remember"]
- Do I install through a company mirror or caching proxy, or run CI jobs that install Python packages: [e.g. "GitHub Actions on every push", "Artifactory mirror at work", "no", "not sure"]
- My time zone: [e.g. "US Eastern", "UTC+8"]
- Accounts I use: [e.g. "Anthropic API, Claude Pro, OpenAI API, ChatGPT Plus, Gemini API, GitHub, AWS, Hugging Face"]

RULES FOR EVERY COMMAND
1. Never print a secret. Do not run cat, type, less, printenv, env, set, or grep without -l, -c, or -o with a name-only pattern, on any file or variable that may hold a key. Use commands that return only file names, counts or yes/no, such as grep -l, grep -c, grep -o with a name-only pattern, ls and test -f. To check a variable, report only "set" or "not set". To list variable names, use a pattern that stops at the equals sign, such as grep -oE '^(export )?[A-Za-z_]+=' and nothing that prints the rest of the line.
2. Never quote a key back to me, not even part of it. Name the provider from the variable name or file location. If you cannot tell, write "unknown provider" and give the path.
3. Do not start Python, pip, uv run, uv sync, uv lock, poetry, pipx, pytest or any Python-based tool until stage 2 says the machine is clear or I say yes. Use shell commands only (find, ls, grep, lsof, docker images). Reading a text file such as a lockfile or a METADATA file with grep is fine.
4. Change nothing (no deleting, killing, uninstalling, editing or pinning) until I say yes to that exact action.
5. If a command needs admin rights or will take more than a few minutes, such as searching the whole disk, tell me first and offer a narrower search.

STAGE 1. Look for the bad version, with shell commands only.
a) Search my home folder, plus the usual system Python locations for my computer, for: folders named litellm-1.107.0.dist-info; files named cook.pth or cook.py inside any site-packages folder; any sitecustomize.py inside a site-packages folder. Include virtual environments, conda environments, uv tool environments and pipx environments.
b) Check whether /tmp/.pc_once_72129118c59f5636c0bb or /tmp/remote_code_loader.lock exist. If the lock exists, use lsof (or the nearest equivalent on my system) to see whether a process holds it, and report only the process ID and command name.
c) Search lockfiles and requirement files under my code folders (uv.lock, poetry.lock, Pipfile.lock, requirements*.txt, pyproject.toml) for litellm 1.107.0. Also list every file that asks for litellm with an open-ended range, such as litellm>= with no upper limit.
d) If Docker is installed, list local images whose name contains litellm, with their digests and created dates, and flag any tagged v1.107.0, latest, main-latest or main-stable that was created on 21 October 2026, or whose digest matches the bad image index LiteLLM published, sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. If Docker is not installed, say so.
e) For each litellm install you find, read its version from the folder name or its METADATA file, never by running Python, and say which project or tool environment it belongs to.
Show me a table: location, what you found, version, which project or tool it belongs to.

STAGE 2. Decide which case I am in, and say it in one line.
- AFFECTED: you found litellm 1.107.0, cook.pth, cook.py, a marker file, or a bad image. Say "Affected" and list the evidence.
- CANNOT TELL: you found nothing, but I installed or updated Python packages or pulled a LiteLLM image on 21 October 2026, or a project uses an open-ended litellm range, or I said "cannot remember", or I install through a mirror or caching proxy (some kept serving 1.107.0 after PyPI removed it, so the window may run later for me), or a CI job installed Python packages on 21 October 2026. If a CI job is involved, tell me StepSecurity says to treat every secret exposed to that job as stolen, and add each one to the checklist. Explain that LiteLLM says finding nothing does not prove an environment is clean, because containers and temp cleanup remove the evidence. Convert 11:39 to 14:20 UTC on 21 October 2026 into my time zone so I can check my memory and my shell history (search it with grep -c or a pattern that shows only the command name, never the full line), and treat me as affected unless I can rule that window out.
- NOT AFFECTED: you found no 1.107.0 anywhere, no marker files and no bad images, and I installed nothing in the window. Say "Not affected on this evidence", list what you checked, and list anything you could not reach.
If I have DNS or firewall logs, tell me to search them for litellm.dev from 21 October 2026 onwards.
If a sitecustomize.py turned up and nothing else did, do not call it malicious on that alone, because many Python installs ship one. Give me its path and ask whether I want it compared against the hashes in StepSecurity's write-up.

STAGE 3. If AFFECTED or CANNOT TELL: the clean-up plan. Ask before each step.
Show me this plan, numbered, then ask "Shall I do step 1?" and wait:
1. Stop the background loader: end the process holding /tmp/remote_code_loader.lock, if there is one.
2. Delete cook.pth, cook.py and the bad sitecustomize.py, plus any matching cook*.pyc and sitecustomize*.pyc in __pycache__, from every affected site-packages folder, using shell commands, before any Python runs.
3. Pin litellm==1.106.2 in each project or tool that uses it, replace any open-ended litellm range with that pin, and update the lockfile line so it names 1.106.2. Show each file change as a diff and wait for my yes.
4. Delete and rebuild each affected virtual environment from scratch, only after step 3's pin is in place and the lockfile no longer names 1.107.0. Rebuilding is safer than repairing.
5. For Docker: stop containers from the bad image, delete the image, and pull litellm v1.106.2 by digest. Tell me where to find the official digest; never guess one.
6. Run the stage 1 checks again and show me the new table.
If I am NOT AFFECTED, offer only step 3 (the pin) as a precaution.

STAGE 4. Find where my keys live, without showing them.
List every place on this machine that holds an AI or developer credential, as a table: provider, where (path or variable name), type (API key, login, token, SSH key, cloud credential), and how you know (file exists, variable set). Check at least:
- Shell profile files (.zshrc, .bashrc, .bash_profile, .profile, my PowerShell profile): variable names only, such as ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY, HF_TOKEN, GITHUB_TOKEN, AWS_ACCESS_KEY_ID.
- .env files in my home folder and code folders, two levels deep: the file paths and the names of variables that look like keys, never the values.
- AI tool logins: Claude Code (~/.claude/.credentials.json, or a macOS Keychain entry, reported only as present), Codex (~/.codex/auth.json), Gemini CLI (~/.gemini), Cursor, GitHub Copilot, Aider, Continue, Hugging Face (~/.cache/huggingface/token), Ollama.
- Developer credentials: GitHub CLI (gh auth status shows accounts with the token masked; never add --show-token), ~/.git-credentials, ~/.npmrc, ~/.pypirc, ~/.netrc, ~/.docker/config.json, ~/.aws/credentials, the Azure and gcloud config folders, ~/.kube/config, and ~/.ssh (key file names only).
- Shell and REPL history (~/.zsh_history, ~/.bash_history, fish history, ~/.python_history): report only a count of lines that look like they set a key, using grep -c. Any key typed into a command goes on the checklist.
- A LiteLLM proxy database, if I run one: every provider key stored in it, plus its master key, virtual keys and database password.
Mark anything you could not check as "not checked" with the reason.

STAGE 5. My rotation checklist.
If AFFECTED or CANNOT TELL, turn the stage 4 table into a checklist ordered by damage: cloud and GitHub first, then paid AI API keys, then logins and everything else. For each item give what to do, where to do it, and which file or variable on this machine needs the new value afterwards. Use these pages; if one has moved, say "page may have moved" and tell me what to search for:
- Anthropic API keys: https://platform.claude.com/settings/keys (create the new key, update where it is used, then delete the old one from its three-dot menu)
- Claude logins: run /logout in Claude Code, then on claude.ai open Settings, Account, Log Out to sign out of every device, then sign in again
- OpenAI API keys: https://platform.openai.com/account/api-keys
- ChatGPT logins: Settings, Security and login, Active sessions, Log out all. Codex CLI: run codex logout, then log in again
- Gemini API keys: https://aistudio.google.com/apikey (create the new key, update where it is used, then delete or disable the old one)
- GitHub: Settings, Applications, Authorized OAuth Apps, and revoke GitHub CLI plus any app I do not recognise; Settings, Developer settings, Personal access tokens, and delete and replace each token; then run gh auth login again
- Hugging Face: https://huggingface.co/settings/tokens
- Cloud (AWS, Azure, Google Cloud): deactivate and replace access keys in the provider's console, and if a cloud role was reachable from this machine, tell me to check that provider's activity logs from 21 October 2026 onwards
- SSH keys: make new keys, add them where the old ones were used (GitHub, servers), then remove the old public keys there
- Saved browser passwords and cookies: list the browsers on this machine, tell me to change the most important passwords first (email, bank, work), and sign out of all sessions on those accounts
- Anything else in my table: mark it [CHECK IN APP] and tell me what to look for
Then tell me to open each paid account's usage page and look for spend from 21 October 2026 onwards that I did not make, starting with https://platform.claude.com/usage and the OpenAI usage page.
If NOT AFFECTED, keep it short: say no rotation is needed on this evidence, list any key sitting in plain text in a .env or profile file with a suggestion for where to move it, and suggest pinning exact litellm versions from now on.

STAGE 6. Self-check before your final answer.
- No secret, or any part of one, appears anywhere in this conversation, including command output. If one did, say so first and put that key at the top of the checklist.
- No Python ran before stage 2 cleared the machine or I said yes.
- Nothing changed without my yes for that exact action, and you list every change you made.
- Every affected, cannot tell or not affected call names its evidence.
- Every place you could not check is listed as "not checked".
- Every link came from this prompt, or you marked it "page may have moved".