Hacker Newsが警告したLiteLLM改ざんPyPI版、Python起動だけで実行

Hacker Newsでは、LiteLLMに関するsupply chain incidentが一気に広がった。ユーザーが共有したのは、PyPI上の1.82.7と1.82.8を調べたBerriAIのGitHub issueで、論点は単なるbugではなくmalicious releaseだったことにある。2026年3月24日のmaintainer updateによれば、特に一つのrelease pathではPython interpreterが起動した時点でコードが走りえた。

issue #24512の技術分析では、1.82.8のwheelにlitellm_init.pthが含まれていたと説明されている。Pythonは起動時に.pth filesを自動処理するため、operatorがLiteLLMをimportしなくてもpayloadが実行される可能性があった。同じ分析では、このpackageがenvironment variables、SSH material、cloud credentialsを収集し、attacker-controlled domainへ送信したとされる。maintainerのstatus threadでは、1.82.7もmaliciousだったが、こちらはlitellm.proxyをimportした時に発火する、より狭いtrigger pathだったと整理している。

• maintainersは問題のpackageをPyPIから削除したと述べている。
• status updateではrelease chain compromiseを調査中で、maintainer account rotationを完了したとしている。
• BerriAIは、dependencyをrequirements.txtでpinしているproxy Docker image usersは影響を受けなかったと説明した。

HN discussionが重要だったのは、LiteLLMをroutineなdependency updateではなくincident response案件として扱い直した点だ。公式のrecommendationも明確で、maliciousな.pth fileの有無を確認し、そのpackageが入ったsystemで露出した可能性のある全credentialをrotationし、不正アクセスを監査する必要がある。updateにはGoogleのMandiant teamが調査に加わっていることも書かれている。

agent stackやproxy layerを運用するengineerにとって、より大きな教訓はpackaging trustだ。LiteLLMはmodel credential、vendor API key、infrastructure configの近くに存在するため、install時のcompromiseはそのままprivileged footholdになる。HNの反応はpanicというより、現代のLLM toolingが標準状態でどれだけ多くのsensitive materialに触れられるかを再認識するものだった。

一次情報: technical analysis、maintainer status timeline。コミュニティ出典: Hacker News thread。