Résumé technique : Découverte continue de vulnérabilités dans les systèmes de service des LLM par fuzzing

Énoncé du problème

Les systèmes d'inférence et de service des grands modèles de langage (LLM) (par exemple, vLLM, SGLang) sont devenus une infrastructure critique pour les applications d'IA modernes. Ces systèmes emploient des optimisations agressives telles que la mise en cache des clés et valeurs (KV caching), le regroupement dynamique (dynamic batching), le partage de préfixes, le décodage spéculatif et la planification multi-locataire pour gérer les exigences de calcul et de mémoire des grands modèles. Cependant, cette complexité crée une surface de vulnérabilité distincte et sous-testée au sein de la couche de service.

Les tests de sécurité actuels se concentrent principalement sur le comportement du modèle (par exemple, les jailbreaks, les hallucinations) ou la conformité individuelle des API. Ces approches échouent à capturer les défaillances résultant de la logique d'exécution logicielle de requêtes d'inférence valides lorsqu'elles sont traitées sous des charges de travail concurrentes réalistes. Une analyse empirique récente indique que plus de 35 % des bugs dans ces systèmes se manifestent sous forme d'anomalies non provoquant de plantage plutôt que de pannes totales. Plus précisément, des défauts dans la pile de service peuvent entraîner :

• Corruption silencieuse de l'état : Contamination inter-requêtes où la sortie d'une requête est corrompue par l'état mis en cache d'une autre.
• Pathologies de performance : Déni de service de type « voisin bruyant » où des requêtes valides provoquent une amplification sévère de la latence ou un effondrement du débit pour des locataires sans rapport, sans faire planter le serveur.
• Défaillances de vivacité différées : Plantages déclenchés uniquement par la composition concurrente spécifique de requêtes valides, violant les invariants du planificateur.

Les méthodes de test existantes (évaluations au niveau du modèle, tests API standards et fuzzers conventionnels) n'exercent pas systématiquement les interactions temporelles, de chevauchement et d'état partagé qui déterminent si un système de service préserve l'isolation.

Méthodologie : GRIEF

Pour combler cette lacune, les auteurs présentent GRIEF (GReybox Inference Engine Fuzzer), un fuzzer gris conçu spécifiquement pour les systèmes d'inférence et de service des LLM.

Abstraction centrale : Traces de requêtes temporelles

Contrairement aux fuzzers traditionnels qui mutent des chaînes de bytes ou des invites isolées, GRIEF traite les traces de requêtes multiples temporelles comme des entrées de premier ordre. Une trace est une séquence d'événements côté client horodatés capturant :

• Contenu de la requête : L'invite et les paramètres.
• Structure de planification : Moment où les requêtes se chevauchent, comment elles rivalisent pour l'état partagé, et leurs événements de cycle de vie (ENVOI, ANNULATION, DÉCONNEXION, ATTENTE).
• Identité sémantique : Les requêtes sont regroupées par prompt_family_id pour permettre à GRIEF de faire varier le timing et la concurrence tout en maintenant le contenu de l'invite fixe, isolant ainsi la divergence de la couche de service de la dérive de l'invite.

Boucle de fuzzing et mutations

GRIEF opère une boucle grise qui génère, muté et exécute des traces contre des serveurs en direct, utilisant des retours d'exécution (latence, utilisation des ressources, événements de cache KV) pour guider l'exploration. Il emploie trois classes de mutations au niveau de la trace :

1. Mutations temporelles : Perturbation des décalages d'événements pour modifier le regroupement conjoint, le chevauchement de préremplissage ou le moment de l'éviction du cache.
2. Mutations d'événements : Insertion, suppression ou modification d'événements de cycle de vie pour exercer les chemins de nettoyage, de nouvelle tentative et de démantèlement.
3. Mutations d'éclissage : Combinaison de segments de traces parentes, incluant un éclissage dirigé alignant les phases de réchauffement du cache avec des fenêtres de haute pression pour exposer des conditions de course.

Oracles et pipeline de confirmation

Étant donné que le service des LLM est bruyant et partiellement non déterministe, GRIEF utilise un pipeline en plusieurs étapes pour distinguer les bugs du bruit d'infrastructure :

1. Oracles comportementaux : Détection d'anomalies externes (par exemple, régression sévère de la latence, sorties corrompues, violations de cycle de vie).
2. Confirmation relationnelle assistée par logprob : Les traces suspectes sont rejouées avec un décodage déterministe. GRIEF compare les sorties originales et rejouées. Si elles divergent, il vérifie la log-probabilité du premier token divergent. Si le token original n'est pas un candidat presque égal sous la distribution de rejouage, cela confirme une divergence de la couche de service (par exemple, état KV obsolète) plutôt qu'une ambiguïté de décodage bénigne.
3. Forensique structurelle KV : Pour une attribution haute confiance, GRIEF observe les événements de cycle de vie des blocs de cache KV hors bande pour détecter des anomalies structurelles telles que la réutilisation de blocs entre adaptateurs ou des conflits de hachage de contenu.

Contributions clés

1. Identification d'une nouvelle surface d'attaque : L'article identifie le service d'inférence concurrent des LLM comme une frontière pertinente pour la sécurité où des requêtes valides peuvent déclencher des défaillances d'isolation, de performance et de vivacité.
2. Système GRIEF : La conception et la mise en œuvre d'un fuzzer gris qui traite les traces de requêtes multiples temporelles comme des entrées, mutant le timing des requêtes, les événements de cycle de vie et les paramètres du mode de service.
3. Évaluation empirique : L'évaluation de GRIEF sur vLLM et SGLang, découvrant 15 vulnérabilités potentielles, dont 10 ont été confirmées par les développeurs du moteur. Cela inclut 2 CVE attribuées (par exemple, CVE-2026-7141) et des demandes supplémentaires en attente.

Résultats et constatations

L'étude catégorise les défaillances découvertes en trois classes d'impact :

1. Corruption d'état et défaillances d'isolation

GRIEF a découvert des bugs où l'isolation du cache KV se brise, permettant une contamination de sortie inter-requêtes.

• Symptômes : « Pollution de valeur confiante » (sortie d'une valeur erronée copiée d'une autre requête), « perturbation de la chaîne de raisonnement » (boucles infinies ou chaînes de pensée étendues) et « confusion raisonnement-réponse » (génération d'une réponse avant le raisonnement).
• Mécanisme : Ces défaillances se produisent sans entrées malformées. La requête déclencheuse perturbe l'état de service, faisant en sorte que la sortie de la victime soit déterminée par la position vulnérable du planificateur plutôt que par l'invite de la victime seule.
• Vérification : Un rejouage contrôlé a confirmé que les sorties corrompues étaient bit-à-bit identiques sur différentes invites déclencheuses, écartant l'injection d'invite et confirmant des problèmes de réutilisation d'état.

2. Pathologies de performance (DoS de voisin bruyant)

GRIEF a identifié un bug dans vLLM où une seule forme de requête valide API provoque une interférence sévère inter-requêtes.

• Impact : Le temps jusqu'au premier token (TTFT) de la victime a augmenté de 1 361 fois (de ~12 ms à ~18 s), et le débit utile s'est effondré à près de zéro.
• Mécanisme : Contrairement au blocage de tête de file standard, les traces eBPF ont révélé que le coroutine EngineCore partagé était régulièrement désplanifié par le système d'exploitation. Cela a arrêté le chemin de pilotage du moteur pour toutes les requêtes co-planifiées, privant efficacement des locataires sans rapport alors que le serveur restait en vie et sans erreur.

3. Défaillances de plantage et de vivacité

GRIEF a trouvé des charges de travail qui violent les invariants du planificateur uniquement lorsque des requêtes valides sont composées de manière concurrente.

• Étude de cas : Un plantage de service LoRA dans SGLang déclenché par une combinaison spécifique de haute pression sur le cache KV, de formes d'invites mixtes et d'arrivées d'adaptateurs en rafale.
• Mécanisme : La vue du planificateur des adaptateurs actifs divergeait de l'ensemble chargé, créant un lot invalide qui a déclenché une erreur d'assertion. Le plantage était différé, survenant après un préremplissage normal et des réponses réussies, le rendant difficile à diagnostiquer sans la trace complète.

Signification et affirmations

L'article soutient que la concurrence, la mise en cache et le comportement du planificateur doivent être traités comme des frontières de sécurité et de fiabilité de premier ordre pour l'infrastructure des LLM. Les résultats démontrent que :

• Les tests de sécurité standard des modèles et les vérifications de conformité API sont insuffisants pour sécuriser les systèmes de service des LLM.
• Des requêtes API valides et documentées peuvent induire une corruption silencieuse de la sortie, une interférence inter-requêtes et une perte de disponibilité sans erreurs explicites du serveur.
• La « couche de service » elle-même est une surface d'attaque critique où les bugs peuvent se manifester sous forme d'anomalies subtiles, non provoquant de plantage, invisibles pour la surveillance traditionnelle.

Les auteurs concluent que l'infrastructure future des LLM doit intégrer le fuzzing de la couche de service dans les processus de test et de renforcement routiniers pour atténuer ces risques avant qu'ils ne soient rencontrés en production. Le travail est présenté comme un avertissement précoce et un changement méthodologique vers le traitement du moteur d'inférence comme un composant critique pour la sécurité, et non simplement comme un substrat de performance.