veilletech.frCe qui se passe
Daniel Stenberg, le mainteneur de curl, annonce un changement de procédure pour les failles de sécurité. À partir du 26 octobre 2026, tout rapport de gravité LOW ou MEDIUM doit être déposé comme une issue publique dans le dépôt GitHub de curl. Seules les gravités HIGH et CRITICAL restent privées, sur HackerOne.
En cas de doute sur la gravité, on peut toujours déposer sur HackerOne : le projet indique la gravité qu'il retient. Un rapport jugé LOW ou MEDIUM y sera refermé comme « informatif », rendu public, et son auteur invité à le redéposer sur GitHub. Le projet utilise quatre niveaux, LOW, MEDIUM, HIGH et CRITICAL, avec des lignes directrices publiées sur curl.se.
Pourquoi maintenant
Stenberg parle d'une avalanche de rapports dont il ne voit pas la fin avant plusieurs mois, et d'une équipe « au bord de ce qu'elle peut supporter ». Il décrit deux tendances :
- des chercheurs qui jettent des modèles d'IA sur chaque série de correctifs publiée, pour y trouver des omissions ou des cas voisins ;
- des « combinaisons absurdes » d'options ou d'appels trouvées par des modèles, sans risque réel parce que presque aucune application ne les enchaînerait, ou parce que l'effet inattendu se produirait à chaque fois et serait vu tout de suite.
Plus de 90 % des soumissions des dernières années ont pu être classées sous le niveau HIGH sans longue analyse.
Ce que ça change
- Pour qui livre curl ou libcurl : les failles mineures apparaîtront dans les issues du dépôt, pas dans un avis publié avec une version. Suivre le dépôt devient utile, pas seulement les annonces de version.
- Pour qui signale : estimer honnêtement la gravité avant de choisir où déposer. Stenberg juge presque inouï qu'un chercheur minimise son propre rapport : le risque qu'une faille HIGH atterrisse en public par erreur lui paraît faible.
- Pour les attaquants, une fenêtre un peu plus longue sur des failles que le projet juge peu graves : il assume ce prix.
L'argument en faveur du public : plus de monde pour évaluer le rapport, rédiger l'avis et vérifier que le correctif traite aussi les cas voisins, et des distributions qui suivent plus tôt. Le travail par rapport ne diminue pas, mais il se partage. Ignorer les failles LOW n'est pas retenu : le programme CVE a une procédure d'appel, et si le projet ne délivre pas de CVE pour une vraie faille, quelqu'un d'autre en demandera un. Stenberg dit aussi vouloir refuser plus fermement les rapports sans effet réel sur des utilisateurs.
Source : daniel.haxx.se, 20 octobre 2026. Source en anglais.