Mitigate litellm supply chain compromise (1.82.7, 1.82.8)

[TomasTomecek]

• Exclude litellm==1.82.7 and litellm==1.82.8 from all Containerfiles
  and pyproject.toml — these versions contain a malicious .pth file
  that harvests credentials at Python startup and exfiltrates them via curl
• Add a RUN build step to every Containerfile that fails the build if the
  malicious litellm_init.pth is found in site-packages, as a defence-in-depth
  safety net

litellm 1.82.7 and 1.82.8 were supply-chain-compromised packages published
to PyPI. They contain litellm_init.pth, a .pth file that executes
automatically when Python starts (no import required). The payload collects
SSH keys, cloud credentials (AWS/GCP/Azure), kubeconfigs, CI/CD secrets,
and shell history, then exfiltrates them AES+RSA encrypted to an attacker-
controlled host.

We pull in litellm transitively via beeai-framework==0.1.55, which
specifies litellm>=1.76.1,<2.0.0 — wide enough to resolve to either bad
version. PyPI has since yanked both versions (latest safe is 1.82.6), but
the explicit exclusions make the intent clear and guard against any future
re-publication or similar attack.

Ref: BerriAI/litellm#24512

[gemini-code-assist]

Code Review

This pull request updates dependency configurations in pyproject.toml and several Containerfiles to exclude specific problematic versions of the litellm library (1.82.7 and 1.82.8). It also introduces a security check in the Containerfiles to detect and prevent the use of malicious litellm_init.pth files. The feedback suggests improving the robustness and clarity of the security alert message, specifically by quoting the $MALICIOUS variable to handle filenames with spaces or multiple results, and by redirecting the output to stderr.

[gemini-code-assist]

The error message when a malicious file is found could be improved for clarity and robustness. The current implementation with an unquoted $MALICIOUS variable can lead to garbled output if multiple files are found or if filenames contain spaces. It is also a good practice to redirect error messages to stderr (>&2).

RUN MALICIOUS=$(find /usr /opt -name "litellm_init.pth" 2>/dev/null); \
    if [ -n "$MALICIOUS" ]; then \
      echo "SECURITY ALERT: malicious litellm_init.pth detected:" >&2; \
      echo "$MALICIOUS" >&2; \
      exit 1; \
    fi

[TomasTomecek]

Thanks Gemini but you are just picking nits here, I'm not applying that to all occurences, sorry

[gemini-code-assist]

The error message when a malicious file is found could be improved for clarity and robustness. The current implementation with an unquoted $MALICIOUS variable can lead to garbled output if multiple files are found or if filenames contain spaces. It is also a good practice to redirect error messages to stderr (>&2).

RUN MALICIOUS=$(find /usr /opt -name "litellm_init.pth" 2>/dev/null); \
    if [ -n "$MALICIOUS" ]; then \
      echo "SECURITY ALERT: malicious litellm_init.pth detected:" >&2; \
      echo "$MALICIOUS" >&2; \
      exit 1; \
    fi

[gemini-code-assist]

The error message when a malicious file is found could be improved for clarity and robustness. The current implementation with an unquoted $MALICIOUS variable can lead to garbled output if multiple files are found or if filenames contain spaces. It is also a good practice to redirect error messages to stderr (>&2).

RUN MALICIOUS=$(find /usr /opt -name "litellm_init.pth" 2>/dev/null); \
    if [ -n "$MALICIOUS" ]; then \
      echo "SECURITY ALERT: malicious litellm_init.pth detected:" >&2; \
      echo "$MALICIOUS" >&2; \
      exit 1; \
    fi

[gemini-code-assist]

The error message when a malicious file is found could be improved for clarity and robustness. The current implementation with an unquoted $MALICIOUS variable can lead to garbled output if multiple files are found or if filenames contain spaces. It is also a good practice to redirect error messages to stderr (>&2).

RUN MALICIOUS=$(find /usr /opt -name "litellm_init.pth" 2>/dev/null); \
    if [ -n "$MALICIOUS" ]; then \
      echo "SECURITY ALERT: malicious litellm_init.pth detected:" >&2; \
      echo "$MALICIOUS" >&2; \
      exit 1; \
    fi

[gemini-code-assist]

The error message when a malicious file is found could be improved for clarity and robustness. The current implementation with an unquoted $MALICIOUS variable can lead to garbled output if multiple files are found or if filenames contain spaces. It is also a good practice to redirect error messages to stderr (>&2).

RUN MALICIOUS=$(find /usr /opt -name "litellm_init.pth" 2>/dev/null); \
    if [ -n "$MALICIOUS" ]; then \
      echo "SECURITY ALERT: malicious litellm_init.pth detected:" >&2; \
      echo "$MALICIOUS" >&2; \
      exit 1; \
    fi

[nforro]

I think we need a base image 🙂

[lbarcziova]

thank you!