docs: add LiteLLM supply-chain incident notice to README

[johnnygreco]

📋 Summary

Adds a security notice to the README about the LiteLLM supply-chain incident (March 24, 2026) so users can assess their exposure. This supplements the information already published in the v0.5.4 release notes.

🔗 Related Issue

N/A

🔄 Changes

• Added a security notice section to README.md (before Quick Start) covering the malicious litellm 1.82.7/1.82.8 packages, the five-hour exposure window, and which Data Designer versions were theoretically compatible (only v0.2.2 and v0.2.3)

🧪 Testing

• N/A — documentation-only change

✅ Checklist

• Follows commit message conventions
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[github-actions]

Code Review: PR #516 — docs: add LiteLLM supply-chain incident notice to README

Summary

This is a documentation-only PR that adds a security notice to README.md about the LiteLLM supply-chain incident (March 24, 2026). The notice is placed between the introductory section and the Quick Start section, providing visibility to users assessing their exposure. The change adds 10 lines (including blank separator lines) and modifies no code.

Findings

Accuracy of Claims

Claim	Verification	Status
v0.2.2 (Dec 2025) and v0.2.3 (Jan 2026) had a loose litellm<2 upper bound	v0.2.2 tagged 2025-12-30, v0.2.3 tagged 2026-01-07; both specify litellm>=1.73.6,<2	Confirmed
v0.3.0 – v0.5.3 pinned litellm to >=1.77.0,<1.80.12	v0.3.0, v0.4.x, v0.5.0–v0.5.3 all specify >=1.73.6,<1.80.12 (lower bound is 1.73.6, not 1.77.0)	Minor inaccuracy (see below)
Starting with v0.5.4, litellm is no longer a dependency	litellm does not appear in any pyproject.toml on the current main branch; PR #455 removed it	Confirmed
Both v0.2.2 and v0.2.3 have been yanked from PyPI	Cannot verify from this repo, but claim is stated as a precautionary action	Unverifiable locally

Low — Minor Version Range Inaccuracy

The notice states v0.3.0–v0.5.3 pinned litellm to >=1.77.0,<1.80.12. In reality, these versions specified >=1.73.6,<1.80.12. The >=1.77.0 lower bound was only introduced in PR #417, which landed in v0.5.4 — the same release that removed litellm entirely.

Impact: Negligible. The security-relevant constraint is the <1.80.12 upper bound, which correctly prevented resolution to 1.82.x in all v0.3.0+ releases regardless of the lower bound. No user would reach a different risk assessment due to this discrepancy.

Suggestion: Consider changing >=1.77.0,<1.80.12 to >=1.73.6,<1.80.12 for strict accuracy, or simplify to just <1.80.12 since the lower bound is not relevant to the incident.

Info — External Links

The notice references two external URLs:

• https://github.com/BerriAI/litellm/issues/24518 — BerriAI's incident report (referenced twice)
• https://www.okta.com/blog/threat-intelligence/litellm-supply-chain-attack--an-explainer-for-identity-pros/ — Okta threat intelligence blog

Both URLs are well-formed. Their continued availability depends on third parties, but this is standard practice for security notices.

Info — Placement and Formatting

The notice is positioned prominently between the introductory "What can you do" section and "Quick Start", separated by horizontal rules. This is appropriate for a security advisory — visible without cluttering the main content. The heading uses ### (h3) with a warning emoji, which is consistent with advisory formatting conventions.

Verdict

Approve. This is a well-written, clearly scoped security notice that accurately communicates the exposure window and affected versions. The only finding is a minor inaccuracy in the stated lower bound of the litellm version constraint for v0.3.0–v0.5.3 (>=1.77.0 vs. the actual >=1.73.6), which has no bearing on the security assessment. Consider a follow-up correction for strict accuracy, but it is not a blocker.

[greptile-apps]

Greptile Summary

This PR adds a security notice to README.md about the LiteLLM supply-chain incident (2026-03-24), identifying which Data Designer versions were theoretically exposed and clarifying that all v0.3.0+ releases were protected by the <1.80.12 upper bound. The previously flagged lower-bound inaccuracy (>=1.77.0 → >=1.73.6) has been corrected.

• The notice states that v0.2.2 and v0.2.3 "have been superseded by eight subsequent releases," but git tags show 14 non-RC releases between v0.2.3 and v0.5.4 (v0.3.0–v0.3.8, v0.4.0, v0.5.0–v0.5.3). This factual inaccuracy should be corrected in a security-facing document.

Confidence Score: 4/5

Safe to merge after correcting the release count — all security conclusions are accurate and no code is changed.

One P1 factual inaccuracy remains: the notice claims "eight subsequent releases" between v0.2.3 and v0.5.4 when git tags confirm there are 14. For a security notice, credibility depends on accuracy, so this should be fixed before merging.

README.md line 29 — incorrect release count.

Vulnerabilities

No security concerns introduced by this PR. It is a documentation-only change that informs users about an existing upstream supply-chain incident; no code paths, dependencies, or credentials are modified.

Important Files Changed

Filename	Overview
README.md	Adds a security notice section about the LiteLLM supply-chain incident; one factual inaccuracy — "eight subsequent releases" should be "fourteen" based on git tags.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Assess LiteLLM Supply-Chain Exposure] --> B{Data Designer version?}
    B -- "v0.2.2 or v0.2.3" --> C{Ran pip install/update\non 2026-03-24\n10:39–16:00 UTC?}
    B -- "v0.3.0 – v0.5.3\nlitellm pinned to\n>=1.73.6,<1.80.12" --> F[✅ Not affected\nupper bound blocks 1.82.x]
    B -- "v0.5.4+" --> G[✅ Not affected\nlitellm removed as dependency]
    C -- "Yes" --> D{Did litellm 1.82.7\nor 1.82.8 install?}
    C -- "No" --> E[✅ Not affected]
    D -- "Yes" --> H[⚠️ Potentially affected\nSee BerriAI incident report\nfor remediation]
    D -- "No" --> E

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: README.md
Line: 29

Comment:
**Incorrect subsequent-release count**

The notice says v0.2.2 and v0.2.3 "have been superseded by eight subsequent releases," but the git tags show 14 non-RC releases between v0.2.3 and v0.5.4: v0.3.0–v0.3.8 (9 releases), v0.4.0, v0.5.0–v0.5.3. In a security notice, getting this factual detail wrong can undermine reader trust.

```suggestion
The only Data Designer releases that could resolve to these versions are **v0.2.2** (Dec 2025) and **v0.2.3** (Jan 2026), which carried a looser `litellm<2` upper bound. These are nearly three months old and have been superseded by fourteen subsequent releases — both have been yanked from PyPI as a precaution. All other releases (v0.3.0 – v0.5.3) pinned `litellm` to `>=1.73.6,<1.80.12` and were never compatible with 1.82.x. Starting with v0.5.4, `litellm` is no longer a dependency.
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (3): Last reviewed commit: "Merge branch 'main' into johnny/chore/ad..." | Re-trigger Greptile}

[greptile-apps]

Tip:

Greploop — Automatically fix all review issues by running /greploops in Claude Code. It iterates: fix, push, re-review, repeat until 5/5 confidence.

Use the Greptile plugin for Claude Code to query reviews, search comments, and manage custom context directly from your terminal.