Une vulnérabilité de criticité moyenne a été publiée : CVE-2025-8291. La faille explique que le module ne fait pas une vérification du ZIP64 End of Central Directory. Ce problème de vérification peut induire en erreur à la création d'une archive ZIP.
"La correction conserve ce comportement, mais vérifie que le décalage spécifié dans l'enregistrement du localisateur ZIP64 EOCD correspond à la valeur attendue." précise la CVE à jour.
Django lance 3 mises à jour de sécurité : 5.2.7, 5.1.13 et 4.2.25. Déployez la mise à jour si vous êtes impacté(e).
Deux CVE majeures sont corrigées :
- CVE-2025-59681 : injection SQL dans Query.Set, alias, aggregate, etc.
- CVE-2025-59682 : accès à des dossiers non autorisés via une brèche dans archive.extract()
Django 6, actuellement en développement, est impacté mais ces CVE sont réduites directement dans la version alpha
Annonce : https://www.djangoproject.com/weblog/2025/oct/01/security-releases/
Longtemps considérée comme une question reléguée à un futur lointain, la cryptographie post-quantique (PQC) est aujourd’hui une réalité. Keyfactor a relevé les 6 excuses les plus courantes et explique pourquoi il est urgent de les dépasser.
1. « Nous ne savons pas quels algorithmes seront nécessaires »
Cet argument ne tient plus puisque le NIST a publié les premiers standards PQC en août 2024. Les entreprises disposent désormais d’une base solide pour tester leur interopérabilité et renforcerleur agilité cryptographique. Attendre que « tout soit finalisé » reviendrait à retarder inutilement une transition inévitable.
2. « Nous attendons de voir ce que font les autres »
A l’ère quantique, temporiser revient à s'exposer et à mettre en danger son activité. Les cybercriminels appliquent déjà la tactique du « Harvest Now, Decrypt Later », en collectant aujourd’hui les données pour les déchiffrer demain grâce à la puissance quantique. Pourtant, 24 % des entreprises préfèrent attendre que d’autres ouvrent la voie pour les suivre. Un pari risqué : chaque jour perdu réduit le temps de migration et augmente l’exposition aux menaces.
3. « Ce n’est pas notre priorité absolue »
De nombreuses entreprises continent de reléguer la transition vers le PQC au second plan, alors même que :
Malgré cette prise de conscience, seuls 28 % des dirigeants ont alloué un budget et des ressources humaines pour mener leur migration vers la PQC. Ce décalage entre conscience du risque et action concrète pourrait avoir de graves conséquences. Par ailleurs, les entreprises dont l’autorité de certification racine expire dans les 3 prochaines années doivent obligatoirement préparer leur infrastructure PKI de nouvelle génération.
4. « Nous attendrons que les risques soient imminents »
Un tiers des entreprises (33%) n’envisagent d’agir que lorsque la menace sera tangible. C’est ignorer que le PQC n’est pas une simple mise à jour « clé en main » : il s’agit d’un projet qui exige uninventaire des systèmes, une planification et des tests approfondis. Ce processus prendra plusieurs années. Lorsque la menace sera avérée, il sera probablement déjà trop tard pour réagir.
5. « Les normes et les délais ne sont toujours pas clairs »
C’était peut-être le cas hier mais aujourd’hui le NIST a officialisé les premiers standards PQC et l’Union Européenne a fixé des stratégies claires d’ici 2026 et impose des mises à jour critiques à réaliser avant 2030. Autrement dit, le calendrier est désormais établi et attendre n’a plus de raison d’être.
6. « Nous ne disposons pas des ressources nécessaires »
C’est l’un des arguments les plus fréquents : 40 % des entreprises font état d’un manque de compétences internes, et 31 % invoquent des contraintes budgétaires. Bien que réels, ces freins ne sont pas insurmontables. Comme pour toute évolution majeure de cybersécurité, la clé est de convaincre la direction (avec des arguments solides) et de constituer des équipes d’experts internes sont sécuriser le budget et les talents nécessaires.
« Trop tôt ? Non, déjà urgent » résume parfaitement la situation. La cybersécurité post-quantique n’est pas un chantier que l’on peut repousser. Les normes existent, le calendrier est fixé, et la migration nécessitera plusieurs années mais reporter sa mise en œuvre ne fait qu’accroître les risques.
Pour améliorer la sécurité de NuGet et renforcer la confiance dans les packages, NuGet.or renforce sa sécurité avec le Trusted Publishing. Il s'appuie sur GitHub Actions. L'idée est d'utiliser le GitHub OIDC token ayant une courte vie pour être la clé API NuGet. Ces clés expirent après environ 1h. De facto, la surface de vulnérabilité se réduit et NuGet retire les secrets ayant une longue vie.
Les avantages :
- pas de longue vie des secrets
- des credentials à vie courte, environ 1h
- 1 token = 1 clé
Pour utiliser Trusted Publishing, il faut sélectionner l'action dans le menu utilisateur.
Annonce et exemple : https://devblogs.microsoft.com/dotnet/enhanced-security-is-here-with-the-new-trust-publishing-on-nuget-org/
Depuis quelques mois, les attaques contre la supply chain logicielle se multiplient et constituent une menace malheureusement trop souvent ignorée des développeurs. Or, si des paquets NPM sont compromis, potentiellement, VOTRE propre chaîne peut l'être si vous récupérez des paquets malveillants. "Pour faire face à une augmentation des attaques contre le registre de packages, GitHub renforce la sécurité de npm avec une authentification plus stricte, des jetons granulaires et une publication de confiance améliorée pour restaurer la confiance dans l'écosystème open source." introduit GitHub.
Il faut de la transparence et apporter des réponses à ces attaques notamment contre NPM. Une des dernières en date remonte au 14 septembre avec l'attaque Shai-Hulud qui a compromis des comptes et injecter des scripts post-installation dans des packages très utilisés. En réponse à cette attaque, GitHub a retiré plus de 500 packages et NPM a bloqué l'upload de nouveaux paquets ayant un indice de compromission élevé.
Pour répondre à ces attaques, de plus en plus fréquentes et massives, GitHub a décidé de réagir et propose de changements dans les mécanismes de sécurité :
- authentification à 2 facteurs (2FA) pour les publications locales
- tokens avec durée de vie limitée à 7 jours
- publication certifiée et vérifiée pour pallier aux faiblesses des tokens
- dépréciation des tokens actuels
- interdire les tokens par défaut
- pas de bypass 2FA
GitHub sait que ces nombreux changements impacteront les développeurs : "Nous sommes conscients que certaines des modifications de sécurité que nous apportons peuvent nécessiter des mises à jour de vos workflows. Nous allons déployer ces changements progressivement afin de minimiser les perturbations tout en renforçant la sécurité de npm. Nous nous engageons à vous accompagner tout au long de cette transition et vous fournirons les prochaines mises à jour avec des échéanciers clairs, de la documentation, des guides de migration et des canaux d'assistance."
Pour les mainteneurs de paquets NPM, GitHub préconise une utilisation de la publication de confiance au lieu de tokens, généraliser le 2FA et utiliser WebAuthn au lieu de TOTP
Notre avis : GitHub a le mérite de prendre en main la sécurité des packages et d'inciter à des changements profonds même s'il doit les imposer. Il y a trop d'attaques et de campagnes de phishing contre NPM, PyPi, etc. Et malheureusement, la réponse de ces référentiels est malheureusement trop lente, pis, inexistante. La supply chain de développement est vitale. Sa compromission est une réelle danger pour les développeurs, les entreprises et in fine, les utilisateurs.
Changez vos identifiants PyPi au plus vite ! C'est un peu le conseil urgent de Seth Larson, expert en sécurité à la fondation Python. Une nouvelle campagne de phishing s'attaque à PyPi. Les hackers veulent semer le doute dans les noms de domaine utilisés. Ce phishing cible les utilisateurs de PyPi via une campagne de faux mails demandant à vérifier l'adresse mail pour une maintenace de sécurité (sic). Ce faux mail utilise le domaine pypi-mirror.org. Seth précise que ce domaine ne dépend pas de PyPi ou de la fondation.
Si vous avez cliqué sur le lien : changer immédiatement vos identifiants et vérifier vos logs et historique d'activité.
Le post de Seth : https://blog.pypi.org/posts/2025-09-23-plenty-of-phish-in-the-sea/
Kali Linux est une des distributions Linux pour le pentest et le hacking les plus connues. La version 2025.3 vient d'être annoncée. Elle est toujours basée sur Debian. Elle introduit une dizaine de nouveaux outils dont Nexmon. Nexmon permet de monitorer et de faire de l'injection vers une Raspberry Pi. Parmi les nouveaus outils de hack, citons Caido et Caido-cli, un outil d'audit pour la sécurité web, Gemini CLI, vwifi-dkms, pour éprouver le réseau wifi. llm-tools-nmap permet d'utiliser un LLM pour découvrir et scanner ne nmap. A noter que ARMel n'est plus supporté.
Liste complète des outils introduits dans la 2025.3 :
Site : https://www.kali.org/
Note de version complète : https://www.kali.org/blog/kali-linux-2025-3-release/
Les attaques contre les NPM, GitHub et la chaîne logicielle globalement, posent de réelles questions sur l'intégrité des extensions et des codes. GitHub propose une fonctionnalité qui pourrait nous sauver, du moins, partiellement, "c’est le genre de truc que tous les développeurs devraient activer illico sur leurs repos." commente Korben. Il s'agit de l'immutable releases. La notion d'immutable, d'immutabilité, est importante en informatique.
En gros, l'immutable est un asset technique que l'on ne peut pas changer, modifier. Il peut être en lecture seule. Un élément immutable ne change pas et on ne peut pas le corrompre. On parlera en Français d'immuable. En programmation, on parle aussi d'immutable.
Par la fonction immutable release, théoriquement, on bloque les attaques essayant d'injecter ou de corrompre notre dépôt. Bref, cette fonction doit bloquer :
Il n'est jamais inutile de rappeler le TOP 10 LLM de l'OWASP. La version 2025 est disponible. Plusieurs changements importants apparaissent dans les failles potentielles.
Voici un récapitulatif des vulnérabilités LLM :
LLM01 : prompt injection
Une vulnérabilité d'injection d'invites se produit lorsque les prompts des utilisateirs modifient le comportement ou le résultat du LLM de manière inattendue. Ces entrées peuvent affecter le modèle même si elles sont imperceptibles pour l'utilisateur. Par conséquent, les injections d'invites n'ont pas besoin d'être visibles/lisibles par l'utilisateur, tant que le contenu est analysé par le modèle.
Contre-mesures : contraindre l'usage du LLM, bien définir le format et les données en sortie et en entrée, renforcer les droits, validation humaine pour les demandes les plus critiques, isoler les données externes
LLM02 : données sensibles sont dévoilées / accessibles
Les informations sensibles peuvent affecter le LLM et son contexte d'application. Cela inclut les informations personnelles identifiables, les données financières, les dossiers médicaux, les données commerciales confidentielles, les informations d'identification de sécurité et les documents juridiques. Les modèles propriétaires peuvent également avoir des méthodes de formation spécifiques et un code source considéré comme sensible, en particulier dans les modèles fermés ou de fondation.
Contre-mesures : renforcer les accès aux données, sensibiliser les utilisateurs sur l'usage sécurisé des LLM
LLM03 : supply chain
Les chaînes d'approvisionnement LLM sont exposées à diverses vulnérabilités, susceptibles d'affecter l'intégrité des données d'entraînement, des modèles et des plateformes de déploiement. Ces risques peuvent entraîner des résultats biaisés, des failles de sécurité ou des pannes système. Alors que les vulnérabilités logicielles traditionnelles se concentrent sur des problèmes tels que les défauts de code et les dépendances, en ML, les risques s'étendent également aux modèles et données pré-entraînés tiers.
Contre-mesures : vérifier la source des données, utiliser des LLM validés, monitorer l'activité de la supply chain
LLM04 : données corrompues
L'empoisonnement (=corrompues volontairement) des données se produit lorsque les données de pré-entraînement, de réglage fin ou d'intégration sont manipulées pour introduire des vulnérabilités, des portes dérobées ou des biais. Cette manipulation peut compromettre la sécurité, les performances ou le comportement éthique du modèle, entraînant des résultats néfastes ou une altération des fonctionnalités. Les risques courants incluent une dégradation des performances du modèle, un contenu biaisé ou toxique et l'exploitation des systèmes en aval.
Contre-mesures : tracer la donnée (source et transformation), valider les sorties, mettre en sandbox les données externes non validées, intégrer du RAG dès l'inférence
LLM05 : sortie incorrecte
La gestion incorrecte des sorties fait spécifiquement référence à une validation, un nettoyage et une gestion insuffisants des sorties générées par les LLM avant leur transmission vers d'autres composants et systèmes. Le contenu généré par LLM étant contrôlable par une saisie rapide, ce comportement revient à fournir aux utilisateurs un accès indirect à des fonctionnalités supplémentaires. La gestion incorrecte des sorties diffère de la surdépendance en ce qu'elle traite les sorties générées par LLM avant leur transmission en aval, tandis que la surdépendance se concentre sur des préoccupations plus larges liées à la dépendance excessive à l'exactitude et à la pertinence des sorties LLM. L'exploitation d'une vulnérabilité de gestion incorrecte des sorties peut entraîner des attaques XSS et CSRF dans les navigateurs web, ainsi que des attaques SSRF, une élévation de privilèges ou l'exécution de code à distance sur les systèmes back-end.
Contre-mesures : approche zero trust, vérifier strictement les entrées et les sorties, ne pas autoriser des sorties non prévues, application stricte des règles et limitations, monitorer les sorties LLM
LLM06 : Excessive agency
Ce problème est une vulnérabilité affecte les actions suite à des résultats inattendus ou manipulés. Les principales causes : hallucinations, pauvre qualité du prompt, injection directe pour compromettre le comportement et les réponses. Les causes de l'excessive agency peuvent être des excès de permissions ou d'autonomie de fonctionnement, une saise non sécurité, non contrôlée
Contre-mesures : limiter l'action des agents, limiter les permissions des extensions et l'action des LLM, validation humaine pour certains prompts et des réponses sensibles. Nettoyer les demandes et les réponses
LLM07 : système de prompt défaillant
Le système prompt est là pour orienter, définir les réponses et les usages. Si ce système n'est pas bien déployé ou défini, cela peut entraîner hallucinations et mauvais usages
Contre-mesures : encadrer et limiter l'accès aux données sensibles, installer des garde-fous
LLM08 : vecteurs et vulnérabilités embarquées
Les vulnérabilités liées aux vecteurs et aux intégrations présentent des risques de sécurité importants dans les systèmes utilisantdu RAG avec des LLM. Les faiblesses dans la manière dont les vecteurs et les intégrations sont générés, stockés ou récupérés peuvent être exploitées par des actions malveillantes (intentionnelles ou non) pour injecter du contenu nuisible, manipuler les résultats des modèles ou accéder à des informations sensibles.
Contre-mesures : installer un contrôle d'accès, authentification des sources de données et validation des données, monitoring du système, classification des données selon la sensibilité
LLM09 : désinformation
L'une des principales causes de désinformation est l'hallucination : le LLM génère un contenu apparemment exact, mais fabriqué de toutes pièces. Les hallucinations surviennent lorsque les LLM comblent des lacunes dans leurs données d'entraînement à l'aide de modèles statistiques, sans en comprendre véritablement le contenu. Par conséquent, le modèle peut produire des réponses apparemment correctes, mais totalement infondées. Si les hallucinations sont une source majeure de désinformation, elles ne sont pas la seule cause ; les biais introduits par les données d'entraînement et les informations incomplètes peuvent également y contribuer.
Contre-mesures : déployer un RAG, tuning fin des modèles, vérification croisée automatique et humaine, bonnes pratiques sur l'usage et sur le code d'intégration
LLM10 : consommation excessive / inattendue (de l'infrastructure, du service LLM ou IA)
Les attaques visant à perturber le service, à épuiser les ressources financières de la cible, voire à voler la propriété intellectuelle en clonant le comportement d'un modèle, reposent toutes sur une même classe de vulnérabilité de sécurité pour réussir. La consommation illimitée se produit lorsqu'une application LLM (Large Language Model) permet aux utilisateurs d'effectuer des inférences excessives et incontrôlées, entraînant des risques tels que le déni de service (DoS), des pertes économiques, le vol de modèles et la dégradation du service. Les exigences de calcul élevées des LLM, en particulier dans les environnements cloud, les rendent vulnérables à l'exploitation des ressources et aux utilisations non autorisées.
Contre-mesures : limitation les entrée, définir des quotas limites, gestion de timeout, réduire l'accès des LLM aux ressources réseaux ou aux API, dégradation du service en cas de forte charge, réduire le nombre de requête autorisée et réduire la file d'attente
OWASP top 10 LLM : https://genai.owasp.org/llm-top-10/
L'éditeur JFrog a annoncé plusieurs nouveautés sur les agents IA, l'IA en générale et la sécurité.
1 / Ai Catalog : un catalogue IA pour mieux découvrir et déployer les LLM incluant les modèles NVIDIA Nemotron. Disponible dès à présent, cette nouvelle offre permet aux entreprises de créer en des solutions agentiques spécialisées et d’intégrer des services d’IA dans leur chaîne d’approvisionnement logicielle, tout en conservant une visibilité, un contrôle et une conformité complets.
2 / DevGovOps avec AppTrust : une nouvelle offre sur la gouvernance DevOps dans la production logicielle. AppTrust doit aider les entreprises à automatiser et à mieux gérer les exigences d’audit et de conformité sur l’ensemble de leur chaîne d’approvisionnement logicielle, réduisant ainsi les risques et renforçant la confiance dans les applications.
3 / FLY : Fly a été pensé pour offrir aux petites équipes de développement une expérience pilotée par l’IA, sans contraintes, et parfaitement intégrée à GitHub ainsi qu’aux outils d’IA natifs tels que Cursor, Claude Code et GitHub Copilot. Fly est un dépôt d'agents IA
4 / L'éditeur renforce la partie agent. « Nous voulons aider les développeurs à passer d'une sécurité réactive à une sécurité proactive, avec une gestion continue des vulnérabilités et une remédiation autonome, où la sécurité n'est plus une réflexion après coup, mais un élément intégral, un agentic de résolution de problèmes de codage », déclare Asaf Karas, CTO de JFrog Security. « Nos connaissances avancées en matière de recherche sur la sécurité, associées à notre intégration GitHub Copilot, aident les équipes à automatiser des mesures de protection essentielles telles que la correction des CVE et la sélection de paquets sécurisés. Cela permet aux utilisateurs d'innover en toute confiance, tout en réduisant les risques et en accélérant la livraison de logiciels sécurisés. ». La sécurité est un des défis majeurs des agents et de l'IA en général. Les nouvelles fonctionnalités de correction agentique de JFrog sont disponibles dès maintenant dans le cadre des offres de sécurité JFrog Ultimate ou Unified.
Toutes les offres JFrog : https://jfrog.com/