<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 13:56:26 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-59821 — LiteLLM: Custom Code Guardrails production endpoints bypass code safety checks</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-59821</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; BerriAI litellm&lt;/p&gt;
&lt;p&gt;LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.82.0-stable, LiteLLM&amp;#39;s Custom Code Guardrails production create and update paths did not apply the same sandboxing and validation used by the test endpoint, allowing a privileged user with access to create or update guardrails to submit custom Python code that executed in the LiteLLM proxy environment and could expose secrets available to the process. This issue is fixed in version 1.82.0-stable.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; BerriAI litellm&lt;/p&gt;
&lt;p&gt;LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.82.0-stable, LiteLLM&amp;#39;s Custom Code Guardrails production create and update paths did not apply the same sandboxing and validation used by the test endpoint, allowing a privileged user with access to create or update guardrails to submit custom Python code that executed in the LiteLLM proxy environment and could expose secrets available to the process. This issue is fixed in version 1.82.0-stable.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-59821</guid>
    </item>
    <item>
      <title>GHSA-72m8-9m7m-h278 — LiteLLM: Custom Code Guardrails production endpoints bypass code safety checks</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-72m8-9m7m-h278</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;LiteLLM&amp;#39;s Custom Code Guardrails production create/update paths did not apply the same sandboxing and validation used by the test endpoint.&lt;/p&gt;
&lt;p&gt;A privileged user with access to create or update guardrails could submit custom Python code that executed in the LiteLLM proxy environment. In deployments without a configured master key, callers could be treated as proxy administrators, making this reachable without intended administrative authorization.&lt;/p&gt;
&lt;p&gt;This could allow arbitrary code execution in the LiteLLM proxy container and exposure of secrets available to the process.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The issue is fixed in `1.82.0-stable`.&lt;/p&gt;
&lt;p&gt;LiteLLM recommend upgrading to `1.82.0-stable` or later.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible:&lt;/p&gt;
&lt;p&gt;1. Restrict access to `POST /guardrails` and `PUT /guardrails/{guardrail_id}` to trusted administrators only.
2. Ensure `LITELLM_MASTER_KEY` is configured.
3. Avoid enabling Custom Code Guardrails for untrusted users.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;LiteLLM&amp;#39;s Custom Code Guardrails production create/update paths did not apply the same sandboxing and validation used by the test endpoint.&lt;/p&gt;
&lt;p&gt;A privileged user with access to create or update guardrails could submit custom Python code that executed in the LiteLLM proxy environment. In deployments without a configured master key, callers could be treated as proxy administrators, making this reachable without intended administrative authorization.&lt;/p&gt;
&lt;p&gt;This could allow arbitrary code execution in the LiteLLM proxy container and exposure of secrets available to the process.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The issue is fixed in `1.82.0-stable`.&lt;/p&gt;
&lt;p&gt;LiteLLM recommend upgrading to `1.82.0-stable` or later.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible:&lt;/p&gt;
&lt;p&gt;1. Restrict access to `POST /guardrails` and `PUT /guardrails/{guardrail_id}` to trusted administrators only.
2. Ensure `LITELLM_MASTER_KEY` is configured.
3. Avoid enabling Custom Code Guardrails for untrusted users.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-72m8-9m7m-h278</guid>
    </item>
    <item>
      <title>PYSEC-2026-3478 — LiteLLM: Custom Code Guardrails production endpoints bypass code safety checks</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-3478</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;LiteLLM&amp;#39;s Custom Code Guardrails production create/update paths did not apply the same sandboxing and validation used by the test endpoint.&lt;/p&gt;
&lt;p&gt;A privileged user with access to create or update guardrails could submit custom Python code that executed in the LiteLLM proxy environment. In deployments without a configured master key, callers could be treated as proxy administrators, making this reachable without intended administrative authorization.&lt;/p&gt;
&lt;p&gt;This could allow arbitrary code execution in the LiteLLM proxy container and exposure of secrets available to the process.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The issue is fixed in `1.82.0-stable`.&lt;/p&gt;
&lt;p&gt;LiteLLM recommend upgrading to `1.82.0-stable` or later.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible:&lt;/p&gt;
&lt;p&gt;1. Restrict access to `POST /guardrails` and `PUT /guardrails/{guardrail_id}` to trusted administrators only.
2. Ensure `LITELLM_MASTER_KEY` is configured.
3. Avoid enabling Custom Code Guardrails for untrusted users.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: litellm&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;LiteLLM&amp;#39;s Custom Code Guardrails production create/update paths did not apply the same sandboxing and validation used by the test endpoint.&lt;/p&gt;
&lt;p&gt;A privileged user with access to create or update guardrails could submit custom Python code that executed in the LiteLLM proxy environment. In deployments without a configured master key, callers could be treated as proxy administrators, making this reachable without intended administrative authorization.&lt;/p&gt;
&lt;p&gt;This could allow arbitrary code execution in the LiteLLM proxy container and exposure of secrets available to the process.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The issue is fixed in `1.82.0-stable`.&lt;/p&gt;
&lt;p&gt;LiteLLM recommend upgrading to `1.82.0-stable` or later.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;If upgrading is not immediately possible:&lt;/p&gt;
&lt;p&gt;1. Restrict access to `POST /guardrails` and `PUT /guardrails/{guardrail_id}` to trusted administrators only.
2. Ensure `LITELLM_MASTER_KEY` is configured.
3. Avoid enabling Custom Code Guardrails for untrusted users.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-3478</guid>
    </item>
  </channel>
</rss>
