Journal Supply chain attack : La faille chez Trivy entraîne des fuites massives par LiteLLM

Posté par  . Licence CC By‑SA.
Étiquettes :
15
24
mar.
2026

Épisode précédent : Trivy compromis une seconde fois : la release v0.69.4 était empoisonnée

Et aujourd'hui on apprend que l'outil open-source LiteLLM (une interface pour gérer plusieurs LLM) utilisait le scanner de vulnérabilité Trivy, entraînant la fuite de nombreux identifiants : "Anyone who has installed and run the project should assume any credentials available to [the] LiteLLM environment may have been exposed, and revoke/rotate them accordingly." Un compte se disant "expert en cybersécurité" sur Twitter affirme que le groupe à l'origine de la fuite extorque déjà "several multi-billion-dollar companies". (Aucune idée de la fiabilité de ce compte, juste qu'il a souvent posté très tôt des infos avérées par la suite.)

Bon et puis ça va sans dire mais ça va mieux en le disant : on ne donne pas de clés ni de mots de passe à un LLM. Même si le LLM tourne sur votre infra, si vous y accédez par un quelconque outil, vous ne savez pas ce qui est fait de votre prompt avant ou après transmission au modèle. Après la mode des framework JS et des modules NodeJS, on voit fleurir des dizaines d'outils super-top pour gérer vos agents "10x engineer" mais personne n'a fait de relecture sur ces trucs.

🎼 It's jungle out there 🎜

  • # Inutilisable ?

    Posté par  (site web personnel) . Évalué à 5 (+2/-0).

    on ne donne pas de clés ni de mots de passe à un LLM

    Donc les 99% de devs qui utilisent un LLM qui a accès à leurs fichiers locaux sont mal faisant ?

    Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

    • [^] # Re: Inutilisable ?

      Posté par  . Évalué à 5 (+3/-0).

      malfaisant \mal.fə.zɑ̃\

      Qui se plaît à nuire, à faire du mal à autrui.

      Malfaisant, probablement pas. Imprudents, oui.

      • [^] # Re: Inutilisable ?

        Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

        En deux mots… je l’avais compris comme la mal façon (par imprudence ou à dessein ? ça par contre je ne saurai dire)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Inutilisable ?

      Posté par  . Évalué à 3 (+1/-0).

      Ton LLM n'est pas supposé avoir accès à tous tes fichiers locaux. Généralement les outils CLI (au moins Gemini & Claude) respectent le .gitignore par exemple. Il y a aussi le .geminiignore et d'autres paramètres de permissions selon le modèle.

      • [^] # Re: Inutilisable ?

        Posté par  (site web personnel) . Évalué à 5 (+2/-0).

        Il n'est pas supposé, mais Claude est un logiciel privateur donc bon…

        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

        • [^] # Re: Inutilisable ?

          Posté par  . Évalué à 5 (+3/-0).

          Donc rien de spécifique aux agents LLM. N'importe quel logiciel privateur (voir open-source comme Trivy) exécuté sur ta machine pourrait accéder à tes fichiers… À chacun d'estimer le niveau de confiance qu'il y met. Mais fournir les clés directement, c'est tendre le bâton. Et puis il y a toujours la possibilité de ne pas mettre de secrets dans le répertoire ou carrément d'exécuter l'IA dans une VM/conteneur, ce qui se fait aussi couramment.

      • [^] # Re: Inutilisable ?

        Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

        Généralement les outils CLI (au moins Gemini & Claude) respectent le .gitignore.

        Tu comprends bien que cette affirmation ne vaut absolument rien. Si ton Claude ou Gemini sot vérolés, ils ne respecteront rien. Et a partir du moment ou tu autorise ton IDE (ou même l'utilisateur de l'OS) à y accéder, rien n'empêche un (bout de) programme malveillant d'y accéder.
        La seule nuance, c'est si le programme malveillant tourne côté serveur IA, si l'application malveillante est derrière l’outil CLI (mais c'est rarement le cas).

        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

        • [^] # Re: Inutilisable ?

          Posté par  . Évalué à 4 (+2/-0).

          Comme dit ci-dessus, ça vaut pour absolument tout ce qui tourne sur ta machine. D'ailleurs la fuite dont parle ce journal n'a rien à voir avec l'IA ou le LLM, c'est un scanner de vulnérabilités open-source qui s'est fait trouer.

  • # Relecture

    Posté par  (site web personnel) . Évalué à 10 (+9/-0).

    Alors, la, c'est pas exactement la faute de litellm, ça aurait pu arriver quand même n'importe ou vu que le souci était (sauf erreur de ma part) via une action github. Si un soft que tu utilises est backdooré, ç'est un peu mort.

    Mais sinon, j'ai commencé à regarder le code de litellm, parce que j’étais curieux de voir comment il y a pu y avoir autant de code par une équipe si petite en si peu de temps. 382 PR en 1 semaine, 58 auteurs, 19 releases par semaine, il y a clairement de l'automatisation à un moment.

    Sans surprise, j'imagine qu'il y a beaucoup de LLM, et c'était l'occasion de voir ce que le code donne (j'avais regardé le depot d'openclaw et j'avais été choqué de voir le bordel à la racine). Et j'ai pas été déçu.

    En ouvrant au pif des fichiers, je tombe sur ce code ou j'ai le sentiment que les variables correspondent pas exactement à leur nom. Il y a un deepcopy sans bonne raison, l'organisation des structures semble pifométrique, etc. De même, la fonction get_llm_provider semble faire plus que juste donner le provider, vu que ça donne aussi une clé d'api et une base (et pas un objet provider propre).

    les structures de données semblent assez visiblement inefficaces vu que je vois 3 fois le concept de région (une fois pour aws, une fois pour waston x et une fois pour le reste). Peut être qu'il y a des subtilités qui m'échappe, mais je doute.

    Et à la racine, il y a un fichier uv.lock, mais aussi un poetry.lock, et un requirements.txt, en même temps. 3 fichiers pour agents (CLAUDE.md, GEMINI.md, AGENTS.md). Le nettoyage existe pas.

    Donc bon, on peut pas blâmer litellm pour la compromission résultant d'un vendeur tierce et sans doute de limitation de Github, mais ça reste en effet du code un peu moche et trop complexe.

    • [^] # Re: Relecture

      Posté par  (Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 25 mars 2026 à 15:17.

      Trivy n'a pas besoin d'accès à internet pour fonctionner donc si on applique la règles des moindres privilèges on ne devrait pas lui donner accès. Si tout ve que tu veux c'est scanner des images docker/oci, il n'a besoin d'accéder qu'à ta registry et seulement en pull, pas push.

      Donc bon si tu appliques des mesures propres et ordinaires même l'utilisation d'une image trivy comprise ne devrait pas aboutir à une fuite de secrets de connection.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.